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Introduction 

This  report  provides  a  summary  of  research  and  development  (R&D)  activity  and  accomplishments,  with 
respect  to  the  development  of  SPARNET,  for  U.S.  Army  contract  number  W911QY-11-C-0012  - 
Integrated  Short  Range,  Low  Bandwidth,  Wearable  Communications  Networking  Technologies. 

The  research  and  development  (R&D)  efforts  conducted  in  this  project  were  aimed  at  the 
implementation  of  an  integrated  short-range,  low-bandwidth,  wearable  communications,  sensing,  and 
networking,  based  on  software-defined-radio  (SDR)  technology.  The  operating-objective  of  the  system 
is  to  enable  the  remote  monitoring,  analysis  and  display  of  summary  activity,  physiologic,  and  geo¬ 
location  data  from  free-roaming  dismounted  Warfighters  in  a  variety  of  austere  military  training 
settings.  Work  was  executed  to  systematically  advance  the  Technical  Readiness  Level  (TRL)  of  the 
current  technological  elements  and  expedite  the  realization  of  a  fully-founded  SPARNET  system.  The 
purpose  of  the  system  is  to  provide  a  powerful  means  of  protecting  the  health  and  well-being  of  Soldiers 
while  they  are  engaged  in  physiologically-challenging  training  that  is  conducted  in  harsh  environments. 

The  technological  elements  on  which  the  work  was  based  are  purpose-built,  from  scratch,  to  directly 
address  the  goals  and  requirements  for  the  Spartan  Network  (SPARNET),  as  described  in  the  United 
States  Army  Research  Institute  of  Environmental  Medicine  (USARIEM)  Performance  Work  Statement 
(PWS)  for  SPARNET,  dated  26  May  2010.  The  PWS  sets  forth  specific  demonstration  and  reporting 
requirements.  This  document  reports  the  activities  that  were  conducted  in  the  field  and  in  the 
laboratory,  showing  that  the  performance-objectives  set  forth  in  the  PWS  for  SPARNET  were  achieved 
during  the  span  of  the  base  year  contractual  requirement. 

Research  Discussions 

By  leveraging  the  significant  investments  already  made  by  the  Army  in  applicable,  purpose-built, 
technological  elements,  the  design  of  the  resulting,  integrated  network  was  optimized  to  meet  project 
objectives.  Incremental  advancement  enables  development  of  system-embodiments  that  can  be  more 
immediately-available  for  use  in  small-sized  groups,  while  larger  groups  can  be  supported  as  the 
development  progresses. 

During  the  course  of  the  project,  R.F.  circuit  card  assembly  (CCA)  engineering  activity  was  accelerated 
and  software  modifications  were  implemented  to  address  two,  known  bugs,  as  identified  in  the  project 
proposal.  One  issue  was  related  to  node-registration  in  the  network  code  and  the  other  was  related  to 
software  defined  radio  timing-recovery  loop.  Additionally,  improvements  to  individual  algorithms  that 
support  the  SDR  capability  were  made.  Design  and  architectural  approach  for  the  performance 
assessment  software  to  facilitate  the  capture  and  storage  of  performance  metrics  were  expanded. 
Work  was  undertaken  to  reduce  the  processing  time  required  by  some  algorithms  and  standard 
functions.  The  data  payload  was  increased  from  32-bytes  to  64-bytes.  Newly  assembled  R.F.  circuit  card 
assemblies  (CCAs)  hardware  were  paired  and  calibrated  with  existing  digital  boards. 

The  integration  of  liquid-crystal-displays  (LCDs)  into  the  squad-area  radios,  to  enable  display  of  radio- 
and  user-specific  parameters  was  executed.  Bluetooth  functionality  was  advanced,  tested  and 
integrated.  Zephyr  (Annapolis,  MD)  and  POLAR  (Lake  Success,  NY)  heart-rate  monitoring-capability  are 
supported  via  a  purpose-built  Bluetooth  CCA.  In  addition,  the  repeater  backbone  was  completed, 
integrated  and  tested.  A  hybrid  architecture  of  the  automatic  gain  control  (AGC)  was  designed  to 
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provide  faster  convergence  over  a  broad  range  of  signal  strength.  The  enhanced  registration  scheme 
was  completed,  integrated  and  tested.  Optimizations  of  the  network  layer  to  advance  the  capabilities 
towards  the  tasks  of  Option  years  (1  and  2)  were  implemented.  Bi-directional  communication  was 
attained  as  well  as  enhancements  to  the  improvements  to  the  TOC  database/application  and  the 
instructor's  map  application. 

Extensive  testing  was  done  to  acquire  field-test  data  and  to  validate  the  test  plans  for  the  executions  of 
Demonstrations  1-4.  Issues  observed  in  the  field  during  the  performance  of  Demonstrations  1-4,  were 
thoroughly  investigated.  Comprehensive  testing  of  the  system  was  performed  to  validate  the 
resolutions  of  the  issues.  Increased  levels  of  indoor  and  outdoor  testing  were  conducted  to  support 
corrective  and  refinement  work  on  software  elements  of  SPARNET  in  preparation  for  the 
demonstrations.  Through  numerous  executions,  the  team  enhanced  its  ability  to  efficiently  execute 
field-testing  and  demonstration  scripts.  Increased  levels  of  indoor  and  outdoor  testing  were  conducted 
to  support  corrective  and  refinement  work  on  hardware  and  software  elements  of  SPARNET.  Details  of 
these  activities  are  reported,  in  the  subsections  that  follow. 

1  Specifications 

The  objective  of  this  task  area  was  to  produce  updated  technical  specifications,  ensuring  that  all 
requirements  (functional,  regulatory  and  environmental)  are  reflected  in  suitable  detail  to  provide  for 
efficient  use  in  the  design  and  verification  processes. 

DD1494  activity  was  carried  out  at  appropriate  times  during  the  project,  when  changes  to  the  radiating 
characteristics  of  network-elements  took  place.  This  included  changes  in  modulation  type,  transmission 
power-levels,  antenna  types  and  other  relevant  factors.  We  also  worked  with  an  officer  from  Center  for 
Health  Promotion  and  Preventive  Medicine  (CHPPM)  (Aberdeen  Proving  Ground,  MD)  to  acquire 
approval  for  use  of  rubber  duck  antennas,  to  file  an  updated  Test  Plan,  and  transference  of  approval  of 
Test  Plan  to  current  contract,  W911QY-11-C-0012,  Integrated  Short  Range ,  Low  Bandwidth ,  Wearable 
Communications  Networking  Technologies. 

At  the  onset  of  the  project,  Elintrix  and  USARIEM  collaborated  to  define  the  requirements  that  reflect 
selected  standards  and  user  needs/preferences.  The  Performance  Work  Statement  (PWS)  for  U.S.  Army 
contract  number  W911QY-11-C-0012  sets  forth  specific  demonstration  and  reporting  requirements.  To 
better  understand  the  specifications  and  ultimately  meet  these  requirements,  a  kick-off  meeting  was 
conducted  between  Elintrix  and  USARIEM.  USARIEM  provided  feedback  to  questions  that  were 
periodically  submitted  by  Elintrix,  throughout  the  duration  of  the  project. 

To  clarify  various  aspects  of  the  requirements  set  forth  in  the  PWS,  Elintrix  and  USARIEM  held  several 
telephone  conferences  to  ensure  that  the  test  plan  submitted  to  the  USARIEM  prior  to  the  executions  of 
the  four  required  demonstrations  accurately  established  the  activities  that  that  were  to  be  conducted  in 
the  field  and  in  the  laboratory.  These  activities  were  to  show  that  the  performance  objectives 
associated  with  the  fulfillment  of  the  four  required  demonstrations  for  the  Spartan  network  (SPARNET), 
were  achieved. 

Updated  specifications  were  written  to  ensure  that  all  requirements  were  reflected  in  suitable  detail  to 
provide  efficient  use  in  the  design  and  verification  processes.  The  resulting  specifications  guided  the 
engineering  activities,  ensuring  that  the  specified  functionality,  configuration  and  performance  levels 
were  successfully  addressed.  As  the  incremental  development  progressed  through  each  stage,  other 
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specific  requirements  were  expected  to  emerge.  The  emergence  of  such  requirements  was  possible,  in 
part,  because  the  architecture  of  the  Squad  Area  Network  (SAN)  portion  of  the  overall  system 
conveniently  supports  new,  functional  extensions  and  because  the  analyses  of  data  collected  from  field 
operations  was  expected  to  reveal  helpful,  situation-specific  refinements. 

2  SAN  Radio 

Work  executed  on  the  radio  was  done  to  bring  the  SDR  CCAs  and  associated  software  to  a  level  of 
maturity  that  was  foundational  for  refinement  to  a  cost-reduced  platform,  in  Option  Year  1.  The  work 
involved  incorporation  of  candidate  improvements  that  have  been  identified  in  the  ongoing  research 
and  development  (R&D).  Additionally,  improvements  to  individual  algorithms  that  support  the  SDR 
capability  were  made.  The  SAN  SDR  was  augmented  with  the  addition  of  a  Bluetooth-link  capability. 
The  Bluetooth-link  was  substituted  for  l-PAN  functionality,  as  Bluetooth  capability  is  required  to  connect 
with  commercially-available,  heart-rate  monitors  such  as  those  produced  by  Zephyr  and  Polar.  Design 
and  implementation  of  performance-assessment  software  to  facilitate  the  capture  and  storage  of 
system  metrics  was  executed.  Work  was  undertaken  to  reduce  the  processing  time  required  by  some 
algorithms  and  standard  functions. 

2.1  R.F.  Design  Improvements 

The  objective  of  this  task  was  to  execute  perfective  work  that  was  aimed  at  optimizing  the  performance 
of  various  elements  of  the  R.F.  circuitry.  The  work  involved  incorporation  of  improvements  that  were 
identified  in  the  ongoing  research  and  development  (R&D)  of  the  R.F.  CCAs.  Exemplar  achievements 
include: 

•  Improved  isolation  between  digital  board  and  transceiver,  reducing  conducted  interference 
from  the  digital  board 

•  Addition  of  a  variable  attenuator  in  the  transmitter  circuitry  to  provide  for  transmit  power- 
control 

•  Extended  baseband  filter  response  to  allow  for  higher  symbol  rates 

2.1.1  LNA  Enhancement 

Through  the  addition  of  a  software-adjustable,  variable  resistor,  the  ldB  compression  was  made 
controllable  by  the  system  processor.  This  modification  allowed  the  low  noise  amplifier  (LNA)  to 
dynamically  adapt  to  hostile  R.F.  environments. 

2.1.2  Improvements  to  Variable  Attenuator 

A  PIN  diode  attenuator  in  the  architecture  was  designed  and  simulated  for  an  approximate,  maximum 
attenuation  of  12  dB.  Performance  testing  has  shown  that  there  was  a  need  to  decrease  the  insertion 
loss  and  extend  the  attenuation  range.  This  allowed  for  a  more  balanced  front-end  gain,  in  conjunction 
with  an  internal  limiter-circuit.  These  improvements  to  the  design  were  executed  under  this  task.  A 
high  linearity,  R.F.  Digital  step  attenuator  covering  a  31.5  dB  attenuation  range  in  0.5  dB  steps  was 
integrated.  The  minimum  predicted  insertion  loss  is  ~  O.ldB  with  a  maximum  attenuation  of  ~11.5dB. 
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PIN  Diode  Frequenc^Response/Attenuation  vs.  Current  drive  (mA) 
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Figure  1.  PIN  diode  frequency  response/attenuation  vs.  current  drive  (mA) 


T unable  BPF 

yj 


RXTTX  Switch 


Variable  Attenuator 


Figure  2.  Receiver  chain 

The  pre-selector  filter  rejects  out-of-band  signals.  The  receiver/transmitter  switch  routes  the  signals 
through  the  limiter  and  variable  attenuator  which  combines  to  protect  the  LNA  from  high  level  in-band 
signals.  The  tunable  band  pass  filter  (BPF)  then  attenuates  in-band  signals. 
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The  tunable  BPF  is  followed  by  a  2nd  LNA  and  tunable  BPF.  The  signal  is  then  sampled  by  the  received 
signal  strength  indicator  (RSSI)  and  the  detected  voltage  is  scaled  and  sent  to  the  variable  attenuator.  In 
addition,  the  detected  voltage  is  sent  to  the  processor.  This  aids  in  detecting  in-band  interferers  in  scan 
mode.  The  radio  can  be  powered  down  except  for  the  front-end  prior  to  the  RSSI  detector  and  the 
spectrum  scanned  for  interference  by  using  only  the  tunable  filters.  The  RSSI  also  aides  in  determining 
which  power  amplifier  (PA)  to  select  by  measuring  the  received  signal  strength  and  assuming  reciprocity, 
determines  if  the  low  power  PA  can  be  used  to  save  battery  power. 

2.1.3  Increase  Drive  to  Power  Amplifier 

Performance  and  characterization  tests  have  shown  that  a  more  efficient  transmitter-chain  design  can 
be  achieved  by  adding  amplification  to  the  output  of  the  up-conversion  mixer,  thus  boosting  the  drive  to 
the  power  amplifiers.  Under  this  task,  amplification  was  incorporated  and  circuit-optimization  was 
advanced  to  achieve  higher  efficiencies. 

To  boost  the  drive  to  the  power  amplifiers,  a  circuit  driver  to  control  the  amplification  output  of  the  up- 
conversion  mixer  was  executed.  The  switch  to  a  lower  power  mixer,  which  required  the  addition  of  a 
low  gain  driver  amplifier,  resulted  in  a  more  efficient  transmitter  chain  design.  This  was  the  trade-off 
between  the  added  amplifier  and  the  previous  high  power  mixer.  The  added  amplifier  will  allow  for 
appropriate  drive  levels  to  be  added  to  each  PA  -  Low  Band  (high-power),  High  Band  (high-power)  and 
low-power.  The  Low  Band  and  High  Band  designations  refer  to  the  frequency  range.  Low  voltage  PA's 
cannot  maintain  efficiency  over  a  wide  bandwidth,  therefore  to  maintain  output  power  with  efficiency, 
two  PA's  covering  the  entire  band  are  used. 

Command  line  interface  (CLI)  modifications  to  provide  the  ability  to  change  the  attenuation  level  were 
successfully  completed.  Investigative  effort  supporting  perfective  work  on  the  transmitter  driver  chain 
was  concluded.  An  extensive  characterization  of  the  receiver  and  transmitter  of  the  individual  radios 
was  performed.  Tracking  filters  on  the  R.F.  hardware  were  re-tuned  for  better  efficiency.  This 
enhancement  increased  radio  sensitivity.  Enhanced  command  line  interface  (CLI)  to  automatically 
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program  the  transmit  scale  factors  when  setting  power  amplifiers  (PA)  from  low-power  to  high-power, 
eliminating  the  need  for  manual  reprogramming  was  executed. 

2.1.4  Modification  of  Filter  to  25kHz  Bandwidth 

Simulations  were  performed  to  update  values  of  the  capacitors  and  resistors  in  the  baseband  filter  to 
enable  a  25kHz  bandwidth.  The  modification  of  the  filter  resulted  in  reduced  transit  time  and  an 
increased  symbol  rate. 

The  symbol-rate  and  shape  of  the  symbol  determine  the  amount  of  frequency  bandwidth  that  is 
occupied  during  a  transmission.  Increasing  the  symbol  rate  increases  the  width  of  the  frequency  band 
that  it  will  occupy.  The  system  is  currently  constrained  to  operate  within  a  25  kHz-wide  band. 
Therefore,  the  theoretical  maximum  symbol  rate  is  25  k  symbols/second.  Due  to  practical 
considerations  and  limitations,  the  achievable  symbol  rate  is  significantly  lower.  We  should  expect  to 
achieve  a  symbol  rate  that  is  somewhere  in  the  vicinity  of  0.66  to  0.8  of  the  theoretical  maximum, 
resulting  in  a  maximum  data-rate  of  30  kbps  to  40  kbps.  For  purposes  of  discussion,  assume  a  symbol- 
rate  of  15  k  symbols/second.  This  will  provide  a  data-rate  of  30  k  symbols/second. 

As  an  aside,  the  principal  reason  that  25  k  symbols/second  cannot  be  used  is  because  it  will  result  in  too 
much  energy  being  injected  into  adjacent  bands.  This  is  not  permitted  by  the  regulatory  authorities.  So, 
it  is  necessary  to  lower  the  symbol  rate,  so  that  the  occupied  bandwidth  is  reduced,  along  with  the  out- 
of-band  energy. 

In  summary,  the  maximum  symbol  rate  is  limited  by  frequency-bandwidth  considerations.  Based  on  this 
limit  and  because  there  are  two  data-bits  of  information  per  symbol,  the  data-rate  is  limited. 
Collectively,  this  means  that  we  don't  have  the  option  of  simply  increasing  the  symbol-rate  to  achieve  a 
higher  data-rate,  unless  we  can  obtain  a  wider  frequency-band  in  which  to  operate,  or  we  change  to  a 
different  modulation  type  (which  would  introduce  other  detrimental  effects).  The  bottom  line  is  that, 
for  now,  we're  likely  to  be  limited  to  a  data-rate  around  30  kbps. 

2.1.5  Optimization  of  Power  Amplifier  Matching 

Work  toward  linearization  of  the  high-power  amplifiers  was  conducted.  The  work  included: 
measurements  and  simulations  to  characterize  the  frequency  response  of  the  transmit  chain, 
measurement  of  the  compression  points  of  the  transmit  driver  amplifier,  extraction  of  s-parameters  and 
compression  point  data,  development  of  a  simulation-model  of  the  PAs,  and  simulations  of  the  PA 
layout  to  aid  in  refinement  of  impedance-matching  were  achieved  during  this  period. 

Below  is  the  simulated  result  of  the  pre-distortion.  It  requires  additional  work  to  more  satisfactorily 
achieve  a  flattened  gain-response,  across  the  band,  and  to  increase  the  power  added  efficiency. 
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Figure  4.  Initial  simulation  of  PA  pre-distortion 


2.1.6  Layout  Improvements 

Improved  tuning  of  the  passband  in  the  pre-selector  was  needed  to  reduce  insertion  loss.  Simulations 
indicate  that  this  can  be  accomplished  through  optimization  of  the  layout.  Improvements  to  the  pre¬ 
selector  were  executed  and  refinements  to  the  layout,  to  better  tune  passband,  were  advanced. 
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To  assist  in  the  design  of  the  board  layout,  EM  (electro-magnetic)  simulation  was  used  to  predict  the 
performance  of  the  signals  with  the  traces,  trace  to  trace  coupling,  and  circuits  as  a  complete  system.  In 
other  words,  after  the  circuits  were  simulated  and  verified,  they  were  then  added  to  the  layout  and  a 
final  simulation  of  select  circuits  with  the  layout  was  performed.  This  type  of  simulation  is  particularly 
useful  in  predicting  the  shifts  in  the  filters  due  to  the  layout. 

The  insertion  loss  is  ~  1.5dB  higher  than  simulated  in  portions  of  the  passband.  This  lowers  the  output 
power  and  raises  the  receiver  noise  figure. 


Figure  5.  R.F.  switches  and  pre-selector  filter  schematic 


U1  is  the  SP4T  switch  that  is  used  to  route  signals  from  the  antenna  to  the  pre-selector. 


Previous  filter  topology  (blue)  vs  new  filter  topology  (red)  Previous  filter  topology  (blue)  vs  new  filter  topology  (red) 


Figure  6.  Plot  illustrating  the  difference  in  response  between  the  standard  BPF  topology  and  the  one 

used  in  the  design  without  the  layout 
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The  BPF  corner  frequencies  are  225MHz  to  380MHz.  The  response  of  the  1st  iteration  of  the  pre-selector 
filter  alone  without  the  layout  was  simulated  as  follows: 
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Figure  7.  Simulated  response  of  the  1st  iteration  of  the  pre-selector  filter  alone,  without  the  layout 

The  3dB  bandwidth  extends  from  224.9MHz  to  385.4MHz.  The  Monte  Carlo  response  is  as  follows: 
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Figure  8.  Monte  Carlo  response  of  Figure  7 

The  worst  case  50dB  pts  are  ~  159MHz  and  530MHz. 


Figure  9.  Worst  case  response  at  225MHz  and  380MHz  are:~  -4.1dB  and  -2.6dB  respectively 
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The  layout  was  simulated  and  then  the  components  were  added.  This  resulted  in  a  change  in 
component  values  (2nd  iteration)  from  the  original  design,  as  shown  below: 


Figure  10.  Schematic  components  change  of  caps  and  resistor  values 

The  layout,  including  the  vias  that  was  simulated,  looks  like  as  follows: 


Figure  11.  Layout,  including  the  vias 

The  blue  designators  indicate  the  ports  used  to  attach  the  lumped  element  components.  The  cylinders 
in  the  bottom  diagram  are  the  vias,  attached  to  the  2nd  layer  ground  plane. 

The  new  response  with  and  without  the  layout  is  as  follows: 
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Response  without  layout  (blue)  &  with  layout  (red)  vs.  Freq. 
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Figure  12.  The  new  response  with  and  without  the  layout 
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Response  without  layout  (blue)  &  with  layout  (red)  vs.  Freq. 
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Figure  13.  The  new  response  with  and  without  the  layout 


MonteCarlo  Response  with  layout  vs.  Freq 
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Figure  14.  Monte  Carlo  response  with  markers  indicating  narrowest  predicted  response 
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From  the  attenuator  the  signal  is  amplified  by  the  1st  LNA.  This  LNA  has  been  designed  for  linearity  as 
well  as  noise  figure.  The  following  plots  indicate  performance. 


Gain(red)  &  Noise  Figure(blue)  vs.  Freq 
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LNA  Gan  &  UP3  vs  Freq 


RFfreq 

Figure  17.  Plot  of  LNA  performance  with  layout 

Over  the  band  of  interest  (225-380MHz)  the  noise  figure  is  ~  1.7dB.  The  gain  simulates  to  ~  19dB 
without  the  layout  effects.  The  input  3rd  order  intercept  is  ~  -ldBm. 


Gain  &  Noise  Figure  vs  Freq 


Figure  18.  Result  of  the  simulations  compared  to  the  results  without  the  layout  effects 
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As  expected  the  gain  with  the  layout  effects  included  is  ~  ldB  lower  than  without  the  layout  effects.  The 
noise  figure  diverges  from  the  predicted  plot  without  the  layout  as  the  loss  in  the  traces  increases  with 
frequency. 


Input  IP3  &  input  IdB  compression  point  vs  Freq 


Figure  19.  Input  IP3  and  input  ldB  compression  point  vs.  frequency  response 


The  plots  above  that  have  circles  on  the  data  points  indicate  the  response  with  the  layout.  The 
compression  pt  and  MP3  improvement  at  the  lower  frequencies  is  due  to  the  lower  gain.  At  the  higher 
frequencies  there  is  a  mismatch  at  the  harmonics  which  affects  the  linearity  of  the  amplifier. 
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The  tunable  BPF  can  be  tuned  for  bandwidth  as  well  as  center  frequency.  This  allows  for  narrowing  up 
the  bandwidth  in  the  case  of  a  strong  desired  signal  which  provides  for  additional  attenuation  of  the 
signal.  It  also  gives  additional  in-band  blocker  rejection. 


Tunable  Filter  Response 


[Eqn 

|Eqn| 

lEqnl 


bw3dB  =  bandwidth_fiinc(db(S21).  3) 
fc3  =  center_freq(db(S21),  3) 

FilterjQ  =  fc3/bw3dB 

Figure  21.  Plot  of  tunable  BPF  response 
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Using  an  optimizer  and  sweeping  the  filter  the  following  plots  were  generated.  They  indicate  the  tune 
range,  filter  BW,  filter  Q,  and  tune  voltages. 
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Figure  22.  Tune  range,  filter  bandwidth  and  tune  voltages  of  tunable  BPF 

The  design  goal  for  center  frequency  is  shown  in  the  far  left  column.  The  3dB  BW  goal  was  15MHz.  As 
can  be  seen,  the  BW  widened  as  the  frequency  increased  however  the  tunable  coupling  helps  to 
minimize  the  change.  Additionally  the  insertion  loss  changed  from  ~  -11.6dB  @  225MHz  to  -6.5dB  @ 
374MHz.  The  tune  voltages  were  as  follows: 
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Figure  23.  Tune  voltages 

With  the  layout  effects  the  following  results  were  generated: 
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Figure  24.  Tune  range,  filter  bandwidth  and  tune  voltages  of  tunable  BPF,  with  layout 
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Figure  25.  Tune  voltages,  with  layout 


2.1.7  Fabrication,  Assembly  and  Debugging 

Under  this  task,  newly-fabricated,  R.F.  printed  wiring  boards  (PWBs)  were  received  and  sent  to  the 
contract  manufacturer,  where  they  were  populated  with  components  to  produce  finished  circuit  card 
assemblies.  Fully  assembled  R.F.  circuit  card  assemblies  were  received  in  the  Elintrix  laboratory  and 
hardware  debugging  and  performance  characterization  efforts  to  establish  proper  operation  were 
conducted. 
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2.1.8  Performance  Characterization  and  Verification  Testing 

The  work  performed  included  extensive  characterization  of  the  performance  of  the  new  design. 
Afterwards,  revision  7  R.F.  circuit  card  assemblies  were  paired  and  calibrated  with  existing  digital  circuit 
card  assemblies.  Laboratory  and  field  tests  were  conducted  to  characterize  the  performance  of  the 
newly-paired  radios  with  the  Revision  7  R.F.  boards.  Board  pairs  were  tested  in  the  laboratory  to 
validate  that  proper  operation  was  achieved. 

Characterization  of  the  R.F.  boards  puts  the  transmit  QPSK  error  vector  magnitude  (EVM)  @  ~20dBm 
and  30+  dBm  is  ~5.3%  assuming  no  oscillation  in  the  transmit  driver.  The  receiver  sensitivity  is  on  the 
order  of  -HOdBm.  That  is  based  on  a  demodulated  constellation  from  the  analyzer  with  the  recovered 
symbols  in  the  proper  quadrate. 

Software  routines  to  optimize  the  timing  of  the  RF  transmit  activation/deactivation  relative  to  packet 
transmissions  were  designed,  implemented  and  verified.  The  optimization  effort  was  successful.  Highly 
beneficial  reduction  of  the  packet-error-rates  observed  during  field-testing  has  resulted  from  the 
debugging  effort. 

2.2  Digital  Design  Improvements 

A  range  of  work  was  executed  to  optimize  the  performance  of  elements  of  the  digital  CCA,  including 
both  hardware  and  software  designs.  The  capabilities  of  the  foundational  design  were  adequate  to 
meet  demonstration  requirements,  but  some  remedial  modifications  were  undertaken.  The  work 
increased  the  available  number  of  radios  to  a  level  sufficient  to  conduct  network  and  firmware  testing 
for  the  full  duration  of  the  year  1,  base  year. 

Debugging  and  calibration  activity  were  conducted  to  repair  some  digital  CCAs  that  were  previously 
inoperable  due  to  bad  components.  The  eight  boards  that  were  required  to  conduct  tests  and 
demonstrations  were  made  operational  and  available  to  support  R&D  activities. 

Modifications  aimed  at  improving  the  stability  of  driver-circuitry  that  supplies  input  signals  to  the 
analog-to-digital  signal-conversion  process  were  completed.  Through  investigative  work,  testing  and 
collaboration  with  digital-to-analog  (DAC)  experts  at  Analog  Devices,  resolution  to  a  distortion  issue  was 
achieved.  This  issue  was  resolved  by  adding  small  capacitors  between  the  input  pin  of  the  DAC  and 
ground.  This  modification  restored  the  signal  integrity  of  the  DAC  output  to  and  eliminated  the  problems 
that  affected  the  execution  of  Demonstration  1. 

2.2.1  Improve  Processor  Access  to  Memory  Resources 

The  digital  CCA  design  includes  two,  dual-core,  fixed-point,  Blackfin  processors  and  one,  single-core 
MSP430,  digital  signal  controller.  Modification  to  improve  the  flexibility  of  the  design  by  providing  the 
dual-core  processors  with  improved  access  to  memory  resources  was  defined.  Application  notes  from 
the  manufacturers  were  analyzed  to  support  communications  between  the  hardware  connections  and 
of  processor  functionality  optimization. 

A  booting-issue  with  the  two  dual-core  fixed-point  processors  was  discovered.  It  was  identified  that  the 
serial  peripheral  interface  (SPI)  boot  of  DSP1  (1st  processor)  caused  DSP2  (2nd  processor)  to  boot  with  the 
same  code.  The  two  processors  were  being  booted  from  a  single  SPI  FLASH  and  DSP1  and  DSP2  were 
configured  as  both  SPI  Masters.  The  intention  was  to  modify  the  boot  mode  on  DSP2  to  SPI  Slave  and  to 
have  DSP1  load  a  different  application  code  in  to  DPS2. 
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Because  the  memory  space  of  DPS1  was  adequate  to  support  all  operations  required  in  Year  1  activity, 
and  due  to  the  pressing  nature  of  other  project-activities,  the  changes  necessary  to  expand  the 
capabilities  of  the  dual-core  processors,  although  fully  defined,  was  postponed. 

2.2.2  Digital  Automatic  Gain  Control 

CCAs  circuits  were  reworked  to  implement  digital  management  of  circuitry  that  was  previously  driven  by 
analog  circuits,  placing  adjustment  of  the  on  board,  variable-gain-amplifier  under  the  control  of  one  of 
the  two,  dual-core  processors. 

2.2.3  Verification  of  Circuitry  for  Voice-  and  Text-applications 

Previously  designed  audio  circuitry  that  resides  on  the  digital  CCA,  aimed  at  supporting  voice-  and  text- 
driven  applications  were  debugged  and  verified. 

The  author  of  Handheld  Speech  (Amesbury,  MA)  was  consulted  in  regards  to  the  performance  necessary 
to  support  its  speech  application-software.  It  was  determined  that  additional  work  will  be  required  to 
support  the  speech  application-software.  In  particular,  the  bandwidth  of  the  hardware  design  must 
exhibit  a  high-end  corner-frequency  of  at  least  8  kHz  to  ensure  that  the  filter  does  not  cut  off  before  the 
microphone.  It  was  recommended  that  the  hardware  design  be  modified  to  begin  rolling  off  at  450  Hz 
and  be  strongly  attenuated  by  100  Hz. 

The  microphone  filter/amplifier  will  require  component  value  changes  to  adjust  the  bandwidth  of  the 
filters  for  application  usage.  The  DAC  filter  will  need  to  be  redesigned.  Software  code  will  need  to  be 
written  on  the  MSP430  or  Blackfin  to  scale  the  DAC  signal  level.  The  microphone  circuit  is  functional, 
except  for  the  upper  frequency,  and  also  requires  additional  modifications  to  efficiently  support  the 
speech  application. 

There  was  an  option  to  enable  the  current  design  to  work  with  the  application,  but  required  digital 
filtering.  The  high  pass  filtering  will  need  to  be  carried  out  in  the  digital  domain.  The  microphone 
amplifier  can  operate  with  one  OP-AMP  and  then  will  need  to  DC  correct  it  into  the  analog-to-digital 
converter  (ADC).  It  was  determined  that  the  manufacturer's  part  number,  OPA209,  would  work  the  best 
for  this  application.  Modifications  to  the  circuitry  were  postponed  until  Option  Year  1,  where  the  digital 
CCA  was  scheduled  for  a  design  modifications  and  optimization  of  hardware  elements. 

The  results  of  simulations  were  executed  to  define  the  required  design  changes  are  shown  in  Figure  26, 
Figure  27  and  Figure  28,  below. 
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Response  of  angle  low  noise  OP-AMP 


freq,  Hz 


Figure  26.  Response  of  OP-AMP 


ing  help  is  required.  In  this  case  100kHz  sample  clock,  100Hz  40dB  down,  Fc=150Hz. 


Response  of  single  low  noise  OP-AMP 


Figure  27.  Response  of  OP-AMP,  continued 
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2.3  SDR  Algorithm  Improvements 

SDR  algorithm  improvements  were  executed  during  this  period,  which  included: 

•  Implementation  of  low-cost  rework  to  eliminate  intermittent  distortion  caused  by  the 
transmitter-chain  digital-to-analog  (DAC) 

•  Identified/eliminated  intermittent  down-conversion  hand-off  index  error 

•  Identified/eliminated  bug  related  to  circular  buffer  used  in  data  queue 

•  Implemented  routine  to  improve  precision  of  R.F.  transmit  activation/deactivation 

•  Implemented  two-stage,  digital,  automatic-gain-control  (AGC)  to  improve  response  to  signal 
dynamics 

•  Introduced  code  to  aid  processing  time  budgeting  of  tasks  within  the  main  processing  loop 

•  Corrected  a  radio  boot-up  issue  in  receiver,  where  errors  were  seen  on  first  received  packet 

•  Perfective  work  in  the  carrier  lock  detection  scheme  was  completed.  The  scheme  was  revised  to 
use  a  derivative-based  metric  for  lock-detection 

•  Routines  were  amended  to  better  control  configuration  of  the  R.F.  board  between  transmit  and 
receive  states 
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Figure  29.  Notional  SDR  Code-module  Relationships 


2.3.1  Transmit  Chain 

An  issue  was  discovered  in  the  power-up  state  of  the  differential  driver  in  the  transmit-chain  circuitry. 
The  issue  is  related  to  dc  offset  levels  of  the  differential  lines  and  is  only  a  concern  for  the  first 
transmitted  packet,  following  turn-on  of  the  radio.  Resolution  was  pursued  and  accomplished  using  a 
software  fix. 

2.3.2  Demodulator  Carrier-Tracking 

Code  refactoring  of  the  demodulator  carrier-tracking  loop  was  executed  and  improved  packet-error-rate 
performance.  Refinements  to  the  direct  digital  synthesis  (DDS)  and  phase  error  calculation  algorithm  for 
phase  recovery  were  implemented  and  tested.  Optimization  of  proportional  and  integral  constants  was 
performed. 

2.3.3  Received  Signal-strength  Indicator  (RSSI) 

Work  to  replace  the  analog  RSSI  scheme  with  a  digital  methodology  was  undertaken  and  successfully 
completed.  The  digital  approach  relies  on  a  new  energy-calculation  that  is  performed  by  the  processor 
on  the  sampled-data  stream.  Adjustment  of  the  averaging  interval  was  used  to  achieve  the  desired 
smoothing.  The  RSSI  value  generated  is  used  as  a  link  fitness-parameter  to  decide  when  a  new  parent 
node  should  be  engaged. 

2.3.4  Improved  Computational  Efficiency 

Work  was  executed  to  reduce  the  processing  time  required  by  some  algorithms,  particularly  some 
standard  functions  in  the  processor  library.  Carrier-tracking  performance  was  improved. 

Characterization  of  processing-time  required  for  data-packet  transmit-  and  receive-transactions  was 
performed.  This  work  was  conducted  as  part  of  verifying  proper  bi-directional  communication 
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characteristics,  such  as  validating  message  sequences  between  the  instructor  and  student  nodes.  New 
opportunities  to  reduce  processing-time  were  identified. 

2.3.5  Digital  Automatic  Gain  Control  Algorithm 

2.3.5.1  Digital  AGC  Scheme 

An  initial,  improved  algorithm  for  the  digital  control  of  the  automatic  gain  control  (AGC)  was 
implemented.  The  code  produced  a  metric  that  reflected  the  amount  of  gain-control  applied  to  establish 
the  proper  maximum-amplitude  of  packet-samples.  This  metric  forms  part  of  the  information  provided 
to  the  network  layer  to  facilitate  evaluation  of  the  suitability  of  transmitting-nodes  as  potential  parent- 
nodes.  Performance  utilities  integrated  in  the  radio  were  used  to  capture  and  analyze  packet  sample- 
records  under  mobile  conditions.  These  records  were  used  to  optimize  the  attack-rate  of  the  algorithm. 

2.3.5. 2  Hybrid  Automatic  Gain  Control  (AGC) 

Experimental  results  suggested  that  digital  management  of  the  variable-gain  amplifier  (VGA)  that 
provides  initial  AGC  control  would  yield  better  results  over  a  wider  dynamic  range  of  burst  signals.  A 
digital  algorithm  to  control  the  variable-gain-amplifier  was  implemented,  followed  by  a  second,  all- 
digital  AGC  module.  Rapid,  coarse  adjustment  is  achieved  using  the  variable-gain-amplifier  AGC,  while 
the  all-digital  implementation  performs  fine  adjustments  to  the  received  signal. 

The  digitally-controlled  VGA  provides  gain-control  over  a  range  of,  approximately  44  dB.  Currently,  this 
control  range  modifies  the  amplitude  of  signals  levels  that  fall  between  -30  dBm  and  -74  dBm.  The  all- 
digital  AGC  provides  fine-grained  attenuation/amplification  of  the  output  signal  of  the  VGA,  permitting 
operation  on  signal  levels  below  -74  dBm. 

2.4  Software  Improvements 

2.4.1  Power  Management 

Power  savings  on  the  digital  CCA  circuitry  were  advanced.  Functions  were  created  to  modify  the 
Blackfin  core  voltage  and  frequency,  which  saw  a  66mA  (milliamps)  7.2V  battery  current  savings  going 
from  500MHz  at  1.3V  core  to  250MHz  0.85V  core.  Another  savings  of  30mA  of  7.2 V  battery  current  in 
the  MSP430  audio  circuit  was  harvested  by  activating  a  DAC  on  the  MSP430  code.  The  Blackfin  serial 
peripheral  interface  (SPI)  boot  time  was  decreased  from  12  seconds  to  approximately  0.5  seconds.  This 
was  accomplished  by  composing  an  assembly  language  routine  to  modify  the  Blackfin  SPI  clock  during 
SPI  FLASH  boot.  The  MSP430  code  was  also  enhanced  to  support  the  faster  Blackfin  boot  process.  The 
MSP430  now  validates  that  the  Blackfin  boots  successfully  by  monitoring  the  SPI  bus  for  activity  and 
sending  an  SPI  "PING"  command.  If  the  PING  is  not  received,  the  MSP430  will  reset  the  Blackfin  to  boot 
again.  A  function  was  created  for  the  MSP430  to  switch  the  MSP430  core  voltage  between  +2.2V  and 
+3.3V. 

There  are  several  other  power  savings  modifications  to  be  made  on  the  hardware  and  software.  For 
instance,  the  R.F.  board  circuitry  can  be  powered  down  when  not  in  use.  Multiple  cores  can  be  used  to 
further  reduce  dock-speed  and  core  voltage.  Other  power  management  algorithms,  such  as  using 
information  from  the  network  layer  to  schedule  use  of  low-power  and  standby-mode  operation,  and 
network  algorithms  to  establish  topologies  that  minimize  power-consumption  are  planned  for  future 
implementation. 
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2.4.2  Enhanced  Support  for  Field  Testing 

Assessment  tools  were  designed  and  integrated  into  the  code  to  aid  in  characterizing  the  performance 
of  the  individual  radios,  support  regression  testing  and  generally  reduce  the  amount  of  time  required  to 
gain  essential  insights  into  indoor  and  outdoor  radio-performance.  Past  field  testing  has  underscored 
the  desirability  of  having  an  improved  means  of  evaluating  SPARNET  performance,  in  the  field. 
Accordingly,  the  ability  to  store,  retrieve,  display  and  analyze  packet  sample-records  under  mobile, 
dismounted  conditions  was  achieved.  A  packet-error  utility  which  enables  in-field  triggering  on  packet 
errors  and  simultaneous  storage  of  various  signal  buffers  for  subsequent  analysis  was  completed.  It 
triggers  on  specific  types  of  packet  errors  and  provides  for  storage  of  the  contents  of  key  buffers.  This 
enables  subsequent,  detailed  analysis  of  the  contents  of  signal-buffer  contents,  along  the  entire 
processing-chain,  to  identify  the  cause  of  the  error  and  any  anomalous  algorithmic  behavior  that  may  be 
occurring.  This  added  functionality  allows  for  a  "trigger"  capability.  This  trigger  capability  will  allow  us 
to  zero  in  on  a  specific  set  of  errors  and  programmable  to  any  parameter  of  interest.  This  assisted  in 
perfective  work  on  both  software  and  hardware  elements,  and  opened  the  way  to  detailed  channel- 
characterization  studies  that  provided  information  that  was  leveraged  to  improve  the  SAN  radio 
elements  and  applications.  A  command-line-interface  (CLI)  trigger  was  added  to  "dump"  contents  of 
packet  errors  relative  to  ADC,  despun  and  Matched  Filter  captured  data.  A  counter  was  also  introduced 
in  the  code  which  provides  the  number  of  times  a  specific  case  of  error  was  experienced  when  the  radio 
is  powered  on  and  is  receiving  packets  -  data  packets  and/or  test  packets. 

A  range  of  error-detection  mechanisms  are  built  into  the  radio  algorithms,  to  aid  in  detecting,  analyzing 
and  resolving  performance  issues.  These  mechanisms  can  detect  issue  such  as  failure  to  properly 
decode  the  packet  (manifested  as  cyclic-redundancy-check,  CRC,  errors)  failure  to  resolve  ambiguity  that 
is  a  normal  part  of  the  synchronization  process  in  quadrature  receivers  and  failure  to  properly  achieve 
phase-synchronization  in  a  timely  manner  ("preamble"  errors).  Under  normal  operation,  these  types  of 
errors  can  be  expected  to  occur  when  the  received  signal  has  been  sufficiently  degraded  by  the  channel. 

Performance  metrics  integrated  in  the  radio  algorithm  to  capture  and  analyze  packet  sample-records 
under  mobile,  dismounted  conditions  were  constructed,  to  determine  the  cause  of  the  errors.  This 
function  is  able  to  be  commanded  over  the  CLI.  See  below  for  an  example. 


By  typing  "dumptrig"  command  via  the  CLI,  the  choices  of  specific  cases  of  errors  will 
be  listed. 


[29:37] 

[29:42] 

[29:42] 

[29:42] 

[29:42] 

[29:42] 

[29:42] 

[29:42] 

[29:42] 

[29:42] 


sparnetP3>dumptrig 
DUMPTRIG  CHOICES 


0  =  Turn  OFF  Trigger 

1  =  Preamble  Map  Error 

2  =  SNR  Error 

3  =  Pkt  Length  Long 

4  =  Pkt  Length  Short 
g_dumpTrig  =  0 

sparnetP3> [29: 42]  @ 


Typing  "dumptrig"  and  the  number  corresponding  to  the  packet  error  case  will  be 
selected . 


[30:53]  sparnetP3> 

[30:56]  sparnetP3> [30 : 56]  dumptrig  1 
[31:  0]  sparnetP3> [31 :  4]  dumptrig 
[31:  6]  DUMPTRIG  CHOICES 

[31:  6]  ================ 
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[31:  6]  0  =  Turn  OFF  Trigger 

[31:  6]  1  =  Preamble  Map  Error 

[31:  6]  2  =  SNR  Error 

[31:  6]  3  =  Pkt  Length  Long 

[31:  6]  4  =  Pkt  Length  Short 

[31:  6]  g_dumpTrig  =  1 
[31:  6]  sparnetP3>  [31 :  6]  @ 

Once  the  trigger  is  enabled  and  the  parameter  is  chosen,  the  "dump"  command  is  used  to 
discharge  the  contents  of  the  packet  error  relative  to  the  specifications  listed 
below. 

[33:41]  sparnetP3>dump 
DUMP  CHOICES  (time) 


0  =  Raw  ADC 12 

1  =  16-bit  ADC 12 

2  =  Despun  Samples 

3  =  Despun  8th  Samples 

4  =  MF  inputs 

5  =  MF  outputs 

Supplementary  Digital  and  R.F.  CCA's  were  fabricated  and  assembled  to  provide  additional  squad-area- 
network  (SAN)  radios  for  field  and  laboratory  testing.  In  order  to  increase  the  span  of  testing,  the 
routine  that  is  used  to  prepare  and  load  packets  for  transmission  was  re-factored  so  that  test  packets 
would  undergo  handling  that  employed  the  same  code  used  in  actual  network  packets.  This  was  useful 
in  identifying  data-handling  bugs,  which  were  only  manifested  in  the  network  mode  of  operation. 

2.4.3  Liquid-crystal-display  (LCD)  Integration 

Code  modifications  to  integrate  the  Liquid-crystal-display  (LCD)  to  the  SAN  radio  were  engineered, 
implemented,  tested  and  integrated  into  the  SAN  radios.  The  code  displays  8  rows  of  17  characters 
(ASCII  0  to  127)  on  the  LCD  with  a  modified  version  of  the  CLI  printf  function.  The  LCD  has  the  capability 
to  display  the  synthesized  Elintrix  and  USARIEM  graphic  logos,  as  illustrated  below.  There  are  several 
other  text  messages  stored  in  the  MSP430  memory  that  can  be  used  for  test  purposes,  via  the  LCD  CLI 
command. 


a§a 


File  Dog  Glass  Led  Help 


C6 


CO 


Figure  30.  Synthesized  "Elintrix"  logo  on  SAN  radio  LCD 
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Each  mobile  radio  node  has  been  fitted  with  an  LCD  unit.  Code  was  produced  to  continuously  display 
parameters  of  interest.  Information  displayed  via  the  LCD  includes: 

a.  Node  latitude  and  longitude 

b.  UTCtime 

c.  Battery  status 

d.  Transmission  frequency 

e.  Parent-node  identification 

f.  Link-strength  indication-metric 

g.  Number  of  GPS  satellites  acquired 

h.  911  status  (on,  off,  acknowledged) 

i.  Heart  rate 

The  incorporation  of  the  LCD  enabled  satisfaction  of  the  requirement  set  forth  for  Demonstration  2, 
paragraph  2e  of  the  PWS  which  states:  "Demonstrate  the  display  of  all  required  information  at  each 
Student  Node  and  Instructor  Node". 

2.4.3.1  Mechanical  Enhancements 

Mechanical  modifications  of  the  radio  enclosures  to  support  incorporation  of  the  LCD  displays  were 
accomplished.  Acrylic  screens  were  designed  and  fabricated,  as  well  as  modifications  to  the  case  to 
accommodate  screen  cut-outs.  Metalized  mirrors  for  screen  backing  to  improve  contrast  and  block 
printed  circuit  board  (PCB)  from  showing  through  the  screen  were  also  fabricated.  Other  mechanical 
optimizations  relative  to  the  battery  packs  and  power/911  switches  were  executed. 

2.4.4  911  Messaging 

Bi-directional  messaging  was  demonstrated  using  911-messages  that  were  originated  by  the  individual 
field  nodes  and  responses  generated  by  the  TOC  node.  Currently,  911  messages  are  sent  during  the 
unique  time-slot  that  is  assigned  to  each  radio. 

When  a  node  transmits  a  911  alert  by  depressing  the  designated  push  button  of  the  SAN  radio,  the 
alerting  node's  icon  color  scheme  turns  from  green  to  red,  as  represented  in  Figure  31.  The  student  icon 
is  symbolized  by  an  isosceles  triangle  that  is  colored  green  if  the  last  data  packet  received  was 
successfully  routed  to  the  TOC  node. 

A  red  icon  indicates  that  a  participant  has  pressed  their  911-emergency  push  button  and  may  also 
indicate  that  a  critical  threshold  has  been  exceeded.  Both  the  instructor's  handheld  tablet  application 
and  the  TOC  application  have  audible  tones  that  accompany  the  911  alert  once  it  is  enabled  by  the 
alerting  node  and  received  by  the  applications. 

In  Figure  32  a  snapshot  of  the  alert  tab  configuration  window  within  the  TOC  application  has  been 
extracted  which  furnishes  the  time  to  which  the  TOC  application/database  receives  the  corresponding 
node's  911  alert  activation. 
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Figure  31.  Map  Application  Node  Coloring  Scheme 
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Figure  32.  Alert  Window  Displayed  via  TOC  application  for  Bi-directional  911  Messaging 
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2.4.5  GPS  1  Pulse-Per-Second  (PPS)  Interrupt  Callback 

With  the  objective  of  implementing  a  time-domain  multiple  access  (TDMA)  medium  access  control 
system,  individual  network  node  time  is  derived  from  the  1  PPS  signal  available  from  the  on-board  GPS 
module.  The  current  Elintrix  end-node  hardware  platform  includes  a  GPS  module  type  Trimble 
Copernicus  II  (Sunnyvale,  CA).  This  module  provides  a  1  PPS  signal  line  that  generates  a  pulse  with  an 
rms  error  of  +/-  60  ns.  This  signal  is  available  in  each  network  node;  therefore  overall  network  timing 
synchronization  can  be  achieved.  This  feature  is  particularly  useful  for  a  medium  access  mechanism 
based  on  TDMA.  Although  not  the  only  method  of  attaining  network  level  synchronization,  the 
availability  of  GPS  time  reference  on  each  node  provides  additional  benefits  when  compared  to  other 
synchronization  methods. 

By  typical  design  and  implementation,  network  devices  contain  a  local  clock  source  with  certain 
associated  stability  (usually  specified  in  parts-per-million).  The  objective  of  the  time  synchronization 
subsystem  is  to  discipline  this  clock  source  to  the  incoming  1  PPS  GPS  signal.  The  target  was  to  obtain  a 
time  reference  that  provides  a  highly  stable  source  at  the  required  rate.  The  current  platform  required  a 
software  approach  without  further  hardware  modifications.  For  the  software  case,  the  rising  edge  of  the 
incoming  1  PPS  signal  is  used  to  generate  an  interrupt  in  the  processor  (Blackfin).  This  event  is  the 
reference  to  perform  adjustments  on  a  counter  that  provides  the  signal  to  be  adjusted.  Test  processes 
were  developed  to  support  field  testing  and  demonstration  activities.  Enhancements  to  GPS  time¬ 
keeping  to  sustain  node-timing  during  periods  of  GPS-outage  were  made. 

The  driver  for  the  GPS  1  pulse-per-second  (PPS),  an  interrupt  service  routine  which  synchronizes  the  PPS 
interrupt  to  the  Blackfin  processor  counter  was  completed  and  integrated.  A  code  was  created  to 
synchronize  Timerl  from  the  Blackfin  processor  to  1PPS  of  the  GPS  module  with  elapsed  time 
calculation.  Individual  network  node  time  is  derived  from  the  1PPS  signal  available  from  the  on-board 
GPS  module.  This  allowed  network  timing  synchronization  to  be  achieved. 

A  timing  scheme  was  generated  and  integrated  to  synchronize  the  network  messages  to  the  Blackfin 
counter.  Additional  code  will  need  to  be  created  to  synchronize  Blackfin  Timerl  to  1PPS  and  UTC  time. 
This  requires  writing  driver  to  communicate  with  the  GPS  module.  Set-up  is  currently  set  to  only  listen. 

2.4.6  Data  Packet  Payload  Length 

Based  on  discussions  with  USARIEM,  Handheld  Speech  and  internal  engineers,  an  initially-used  32-byte 
packet  payload  was  increased  to  64-byte  packet  payload  for  use  in  tests  and  demonstrations.  This  longer 
packet  accommodates  time  stamp  information,  as  well  as,  latitude,  longitude,  fluid-intake  information, 
accelerometer  data,  inclinometer  data  and  reserved  bytes  for  currently-undefined  physiologic  sensor 
data.  Future  modifications  can  be  gracefully  implemented,  as  may  be  required. 

2.4.6.1  Data  Packet  Definition 

Network  message-sequence  diagrams  and  data  packet  definitions  for  messages  required  for  registration 
between  Student  Nodes  and  Instructor  nodes  were  analyzed  with  the  objective  of  improving  support  for 
test-relevant  field-data. 

SPARNET  network  DATA  packets  currently  provide  the  following  information 

-  Timestamp  (Hour,  Minute,  Second) 

-  Network  ID 
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-  Node  ID  (corresponds  to  time  slot) 

-  Emergency  state  (ON,  OFF,  ACK) 

-  Latitude  Hemisphere 

-  Latitude  Coordinate 

-  Longitude  Hemisphere 

-  Longitude  Coordinate 

-  Fluid  Intake  Monitor  data  (mL  consumed) 

-  Battery  level  (Good,  Warning,  Critical) 

-  Parent  node  slot 

-  Registration  time  (time  at  which  first  INVITATION  was  sent  (Instructors)  or  time  of  most 
recent  parent  registration  (Students) 

Some  parameters  require  fewer  bits  than  the  byte-length  currently  assigned  to  them.  In  the  future, 
when  the  parameter-list  and  lengths  have  stabilized,  bits  will  be  packed  into  fields  that  will  not 
necessarily  be  increments  of  one  byte. 

2.4.7  Flash  Storage  and  Download 

An  architectural  design  for  storage,  formatting,  downloading  and  subsequent  exporting  of  data  stored 
on  an  individual  node  was  devised.  During  network  operations,  each  radio  stored  the  content  all  data 
packet  information  that  are  self-originated.  The  storage  medium  is  FLASH  memory. 

An  RS-232  cable  is  currently  used  to  connect  to  the  Bluetooth  dongle  and  establish  a  Bluetooth 
connection  between  the  radio  and  the  tablet.  This  cable  is  used  to  download  the  stored  data  from  each 
node  to  a  Windows-based  PC. 

2.4.7. 1  Decoding  of  Downloaded  FLASH  Packet 

The  first  step  in  exporting  the  stored  data  and  information  from  the  individual  nodes  is  to  "dump"  the 
FLASH  log  file  via  HyperTerminal.  HyperTerminal  is  a  terminal  emulation  program  capable  of  connecting 
to  systems  through  TCP/IP  Networks,  Dial-Up  Modems,  and  COM  ports.  HyperTerminal  works  when 
directly  connected  to  the  radio  CLI. 

Below  are  steps  to  create  a  HyperTerminal  log  of  FLASH  log  dump. 
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1)  Start  HyperTerminal  and  connect  to  radio  CLI  COM  port  with  57600  N,8,l  and  no  flow  control. 


2)  Select  Capture  Text  from  Transfer  menu. 
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3)  Select  filename  for  log  and  select  Start: 


4)  Enter  "dump  8"  to  start  FLASH  dump..  In  the  example  below  18,750  bytes  will  be  downloaded  from 
FLASH: 
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5)  At  end  of  FLASH  log  dump,  the  message  Dump#8  Success!!!  will  appear: 


6)  Then  close  the  log  file  by  selecting  Stop  as  indicated  below: 
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7)  Next  step  will  be  to  examine  contents  of  the  FLASH  log  file  using  Parsing  tool. 

2.4.7.2  Python  Parsing  Tool 

A  parsing  tool  was  devised  to  provide  the  capability  to  make  the  downloaded  FLASH  files  in  to  a 
readable  format.  This  was  implemented  using  a  Python  parser  for  the  Flash  dump  to  be  performed  on 
any  Windows  PC. 

Currently,  a  raw  Flash  data  file  consists  of  a  text  header,  multiple  50  byte  packets  for  a  given  SPARNET 
radio,  and  text  footer.  A  given  line  of  the  packet  data  consists  of  one  integer  followed  by  a  comma  and 
there  is  no  distinguishing  character  that  separates  one  packet  from  another.  A  50  byte  packet  consists  of 
a  12  byte  header,  a  36  byte  payload,  and  a  2  byte  CRC. 

The  utility  parses  the  raw  Flash  data  into  a  form  that  distinguishes  one  packet  from  another  and  for  a 
given  packet,  separates  the  header  from  the  payload.  As  each  packet  is  50  bytes  in  length,  the  script 
loops  through  the  dumped  FLASH  file,  buffers  increments  of  50  bytes,  and  processes  the  resulting 
buffer.  The  output  is  a  text  file  which  is  a  cluster  of  individual  parsed  packet  data. 

A  GUI  (graphical  user  interface)  has  been  constructed  to  streamline  the  processes  outlined  above.  Below 
are  screenshots  of  the  GUI  and  the  steps  to  parse  the  dump  of  the  FLASH  file. 

1)  Start  the  software: 


1*  f  l*-h  Dmx>  ' 

I 
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2)  Select  File  from  the  main  menu. 


m 

Oc** 

Import 

SM 

Q* 


L*IM 


3)  Select  Import  from  the  File  drop-down  menu. 


'v  e 
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4)  Click  the  browse  button  and  select  the  file. 


d 


5)  Click  the  OK  button  on  the  file  selection  pop  up. 
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The  two  images  below  present  functionalities  that  have  been  incorporated  into  the  parser  after  the 
execution  of  Demonstration  4.  Namely,  instead  of  using  HyperTerminal  to  import  data  from  the  radio, 
we  can  use  the  Python  parser  itself.  The  functionality  was  built  in  at  the  time.  A  script  was  already 
produced  to  read  data  directly  from  the  serial  port  in  Python.  The  enhanced  code  required  additional 
test  time  prior  to  full  integration  and  with  little  bandwidth  left  prior  to  the  execution  of  Demonstration 
4,  inclusion  was  deferred. 

1)  Setup  drop-down  menu. 


Br,Mh  r**fl 

l* 


Zl 


2)  Serial  configuration  popup. 
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3  Bluetooth  Option  Card  Development 

A  Bluetooth  option-board  was  designed  and  implemented  which  enabled  wireless  connection  to  heart- 
rate  monitors.  The  Bluetooth  link  was  executed  to  satisfy  the  requirements  set  forth  for  Demonstration 
3  of  the  PWS. 

3.1  Development  of  Bluetooth  Board 

Bluetooth-enabled  option-card  schematic  was  designed  and  advanced  to  meet  the  Demonstration  3 
requirement  of  exhibiting  near  real-time  availability  of  Bluetooth-connected  on-body  student  sensor 
information  at  the  Instructor  node  and  TOC  node.  In  addition  to  a  standard  Bluetooth  module,  a 
Bluetooth  Low  Energy  module  was  designed  into  the  board.  The  Bluetooth  option-card,  shown  in  Figure 
33,  was  successfully  advanced  through  design,  layout,  fabrication  and  assembly. 

In  Figure  33,  two,  standard,  Bluetooth  modules  appear  as  large,  silver-colored,  rectangular  packages, 
bounding  the  rectangular  cut-out  at  the  upper,  left  corner  of  the  CCA.  The  left-most  of  these  is  a  break- 
off  board  that  permits  remote  mounting,  if  required,  in  confined  spaces  within  the  SAN  radio  enclosure. 
This  provides  flexibility  in  relocating  the  module,  should  interference  or  blocking  effect  the  other, 
primary  module.  A  Bluetooth  Low-energy  (BLE)  component  occupies  the  dark  area  above  the  left- 
bottom,  gold-plated,  mounting  hole.  This  module  will  enable  research  using  newer  BLE-equipped 
modules  that  are  anticipated  to  appear  on  the  market  in  2012.  The  Bluetooth  board  was  successfully 
debugged,  tested  and  integrated  with  the  digital  Board  of  the  SAN  radio. 


Figure  33.  Fully-assembled  Bluetooth  Option-card  CCA  with  Break-off  Bluetooth  Module 
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3.2  Sensor  Collaborators 

Elintrix  conducted  collaborative  discussions  with  Polar  and  Zephyr  to  obtain  the  permissions,  documents 
and  code  necessary  to  establish  Bluetooth  connectivity  with  their  respective  products. 

An  alternative  to  the  Zephyr/POLAR  sensors  was  the  fluid  intake  monitor  (FIM).  It  can  be  connected  to 
the  Bluetooth  board/dongle  which  can  communicate  with  that  the  Bluetooth  board  for  use  in  the  radio. 
The  hardware  and  software  needed  for  transactions  between  the  radio  and  FIM,  transmission  of  the  FIM 
data,  reception  and  display  are  completed  and  available. 

3.2.1  Zephyr  Protocol 

Engineering  conversations  with  Zephyr  were  conducted  to  define  the  best  reporting-option  for  the 
SPARNET  system.  Considerations  included  the  time-span  retrieved  during  interrogation  of  the 
BioHarness  sensor  and  the  potential  for  blocking  of  the  SPARNET  Squad  Area  Network  (SAN)  radio  by 
out-of-band  emissions  produced  by  the  Bluetooth  transmitters. 

With  respect  to  co-site  interference  produced  by  the  Bluetooth  modules.  Zephyr  technologists  have 
never  experienced  this  problem.  Nonetheless,  an  engineering  discussion  proceeded.  Based  on  the 
results  of  this  discussion,  an  operational  mode  in  which  link-maintenance  transmissions  are  periodically 
executed  was  selected  as  the  first  method  tested. 

Zephyr  software  was  not  received  as  early  as  needed  to  support  the  integration  and  testing  schedule. 
So,  the  integration  of  a  POLAR  heart-rate  monitor  was  executed  to  satisfy  the  Demonstration  3 
requirements.  POLAR  heart-rate  monitors  were  used  during  the  back-to-back  executions  of 
Demonstration  2  and  Demonstration  3.  Subsequently,  in  support  of  Demonstration  4,  the  Zephyr 
BioHarness  3  product  was  successfully  integrated. 

The  integration  of  Zephyr  BioHarness  3  units  was  facilitated  with  the  aid  of  a  senior,  Zephyr,  embedded 
engineer  tasked  to  assist  us  with  integration.  Although  not  displayed,  parameters  other  than  heart  rate 
(such  as  respiration  rate,  accelerometer  and  inclinometer  data)  are  being  interrogated  and  are  available 
within  the  SAN  radio  for  subsequent  incorporation  into  the  data  packet. 

3.2. 1.1  Zephyr  BioGauge  Application  Software 

Zephyr's  BioGauge  software  was  leveraged  to  connect  directly  to  the  on-body  heart  rate  sensors  of  the 
individual  trainee  nodes.  The  purpose  was  to  pair  each  Zephyr  heart  rate  unit  to  the  instructor's  mobile 
device  using  this  application.  Each  student  node's  Zephyr  heart  rate  was  associated  with  the  Bluetooth 
name  that  displays  on  the  connection  screen  inside  the  application.  This  eliminated  the  need  to 
manually  pair  the  heart  rate  units  by  determining  which  COM  port  each  BioHarness  happened  to 
enumerate  on  upon  discovery.  This  was  accomplished  by  terminating  the  SAN  radio's  Bluetooth  link  to 
the  Zephyr  units  by  powering  off  the  radio  units. 

3.2.2  POLAR  Protocol 

Following  execution  of  a  Bluetooth  Transfer  Protocol  License  Agreement  with  POLAR,  Elintrix  was 
immediately  provided  with  POLAR-Proprietary  documentation.  The  documents  include  software  design 
guidelines,  format  information,  flow  charts  and  script  examples  that  enabled  the  development  of  a 
SPARNET-specific  communication-link  with  POLAR  monitors. 
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3.3  Bluetooth  Software  Development 

Work  on  a  range  of  software  drivers  that  were  required  to  facilitate  communication  between  the  new, 
Bluetooth  circuit  card  assembly  (CCA)  and  the  digital  CCA  were  executed.  The  connectivity  between  the 
Bluetooth  board  and  the  radio's  digital  board  was  established.  Communication  of  heart-rate 
information  between  the  SAN  radio  processors  (MSP430  &  Analog  Device's  Blackfin)  was  implemented. 
This  included  enhancements  to  the  MSP430  command  line  interface  (CLI).  Modification  of  the  scheme 
from  polling  to  interrupt-drive  was  performed.  These  modifications  were  incorporated  into  the 
Bluetooth  Option  board  and  Digital  Board  MSP430  processors. 

The  serial  peripheral  interface  (SPI)  messages  were  created  to  accommodate  the  communication  link 
between  the  MSP430  and  Blackfin.  MSP430  interrupts  were  modified  to  properly  transmit  and  receive 
clocked  data  between  the  processors. 

Parsed  "call"  response  from  the  Bluetooth  chip  module  to  show  a  successful  connectivity  and  to  send  a 
response  to  the  Blackfin  was  constructed.  A  scheme  was  created  to  determine  if  the  Bluetooth  radio 
was  in  "command"  or  "data"  mode  and  to  provide  notification  if  connectivity  is  dropped  by  the 
Bluetooth  module.  A  "call"  disconnect  was  implemented  which  will  send  a  parsed  response  to  the 
Blackfin  processor. 

Code  to  enable  the  use  of  the  POLAR  heart  rate  monitor  and  the  subsequent  integration  of  the  Zephyr 
heart-rate  monitor  were  loaded  onto  the  Bluetooth  radio  boards  and  then  fully-integrated  into  the  SAN 
radio  units. 

3.4  Issues 

The  introduction  of  Bluetooth-enabled  heart-rate  monitoring  and  the  10M  tablets  into  the  network 
resulted  in  unexpected,  randomly-occurring  issues  with  radios,  during  Demonstration  2  and 
Demonstration  3.  Information-display  rate/volume  in  field-testing  has  been  increased,  making  Personal 
Digital  Assistants  (PDAs)  impractical  for  continued  use  in  viewing  on-the-fly  communication  and 
topological  information  in  the  field.  Accordingly,  the  PDAs  have  been  replaced  with  10"  Tablets 
(operating  with  Windows)  to  allow  real-time  observation  of  command-line-interface  (CLI)  messages, 
link-quality  and  node-performance.  Collectively,  this  information  is  required  to  facilitate  formation  of 
specific  topologies  for  testing.  It  is  also  worth  noting  that  PDA  devices,  such  as  the  Hewlett-Packard 
iPAQ  (Palo  Alto,  CA)  products  that  have  historically  been  used  in  the  system  have  been  discontinued  by 
the  manufacturer,  as  Android-based  (Google)  (Menlo  Park,  CA)  smart  phones  are  consuming  market- 
share. 

Issues  relative  to  the  Bluetooth  code  were  resolved  during  this  period.  Connectivity  related  issues,  as 
well  as  synchronization  issues  between  the  MSP430  processor  and  the  Bluetooth  WT12  chip  module  in 
the  Bluetooth  Option  board  was  investigated  and  corrected.  Serial  peripheral  interface  (SPI) 
communication  between  the  MSP430  and  Blackfin  processors  was  further  enhanced  by  lengthening  the 
SPI  message  format  from  two  byte  length  field  to  one  byte.  The  issue  of  when  the  Blackfin  supplied  an 
SPI  clock  to  slave  MSP430,  both  MSP430  SPIs  that  resided  on  the  Bluetooth  option  CCA  and  the  digital 
CCA  transmitted  and  received  clocked  data.  It  was  resolved  by  improving  the  MSP430  SPI  interrupts. 

4  Network  Software  R&D 

Mobile  ad-hoc  networks  for  highly  dynamic  military  and  civilian  environments,  such  as  tactical  and 
rescue  mission  communication,  exhibit  several  design  considerations  that  do  not  exist  in  traditional 
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mobile  networks.  Survivability,  fault  tolerance,  dynamic  addressing,  channel  management,  collision 
avoidance,  security  and  mobility  management  are  a  few  of  the  key  problems  that  have  been  the  focus  of 
research  community  in  recent  years.  Several  studies  revealed  that  in  an  ad-hoc  network  with  highly 
mobile  nodes,  the  routing  problem  and  channel  access  problem  must  be  addressed  together.  Studies 
have  also  revealed  that  the  lack  of  fixed  access  points  requires  real-time  self-organization  of  the  mobile 
units  and  dynamic  self  structuring  with  intelligent  access  point  selection.  Among  the  many  problems 
addressed,  routing  and  channel  access  have  been  the  primary  focus  of  the  research  community,  with  an 
extensive  amount  of  work  being  dedicated  to  routing  in  mobile  ad-hoc  networks.  Most  routing 
algorithms  reported  in  recent  research  literature  -  either  table  driven  or  on-demand  routing  protocols  - 
assume  that  the  network  is  stable  during  the  execution  of  the  routing  algorithm  and  also  assume  fixed 
access  points  rather  than  mobile  access  points.  Also,  current  research  has  addressed  routing  and 
channel  access  as  two,  separate  problems.  SPARNET  architecture  is  designed  with  survivability,  fault 
tolerance,  dynamic  addressing,  security  and  mobility  management  in  mind.  The  network  nodes  in 
SPARNET  dynamically  organize  into  clusters  and  utilize  a  novel  leader  election  algorithm  for  cluster 
gateway  election.  In  this  report,  the  target  users  (i.e.  Army  instructors  and  the  soldier-student  team) 
form  and  move  as  a  cluster,  although  there  can  be  considerable  motion  within  the  cluster.  The  soldier- 
students  may,  or  may  not,  all  be  in  the  radio  range  of  the  instructor.  The  network  nodes  move  in  clusters 
and  there  can  be  individual  motion  within  the  cluster. 

The  SPARNET  network  layer  allows  for  the  ad-hoc  creation  and  dynamic,  intelligent  reorganization  of  a 
tiered  network  of  highly-mobile  sensor  nodes.  As  a  dynamic,  self-configuring  network,  countless 
network  topologies  are  possible.  As  a  testable  requirement,  however,  the  network  supported  five 
Student  nodes  and  the  following  topologies  at  the  squad  level: 

1.  Linear  topology 

2.  Star  topology 

3.  Tree  with  a  single  root  node,  one  or  two  branch  nodes,  and  two  or  three  leaf  nodes 

The  network  software  continued  to  be  researched  and  developed  with  the  objective  of  supporting  each 
of  the  milestone  demonstrations  called  out  in  the  USARIEM  SPARNET  PWS,  incrementally  laying  the 
foundation  for  design-improvements  with  which  to  monitor  ever-larger  groups  of  Soldiers. 

Performance-assessment  software  was  developed  to  facilitate  the  capture  and  storage  of  performance 
metrics,  as  required  to  support  demonstrations  and  characterization  tests.  Architectural  changes  to 
improve  the  capability  of  the  network-layer  software  were  advanced.  Specific  areas  under  study 
included:  improved  probability  of  link-availability,  methodologies  for  propagating  path  fitness  based  on 
weighted  metrics  (battery  level,  number  of  subscribed  nodes,  signal-to-noise  ratio,  etc.)  and  hop-depth 
management.  The  network  was  modified  to  enable  the  TOC  to  receive  all  node-specific  data-packets 
directly  from  the  instructor,  rather  than  solely  by  direct  observation  of  the  individual  squad-area- 
network  (SAN)  radios. 

During  this  period,  network  processing-time  measurements  were  made.  The  measurements 
demonstrated  all  packets  were  transmitted  and  received  between  the  instructor  node  and  the  student 
node  as  required  to  complete  registration  of  the  student  nodes.  The  network  layer  was  modified  to 
provide  the  time-of-first-  invitation  from  the  instructor  and  subsequent  time-of-first-registration  by 
students.  This  information  is  presented  by  overlaying  the  data  on  the  map  on  both  the  Instructor's 
mobile  device  (iPAQ  and  subsequently  the  Windows-based  Tablet)  and  the  TOC  application.  This 
enabled  the  analysis  of  the  time  for  first-registration  and  re-registration  processes.  Modifications  were 
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made  and  tested  that  provided  for  improved  control  over  experimentation  with  packet  transmission- 
intervals.  The  capability  was  later  used  to  establish  and  verify  proper  operation  of  the  currently-used 
traffic-timing. 

Work  on  the  registration  architecture  was  executed.  A  node  will  begin  registration  process  with  another 
suitable  parent  when  it  receives  an  energy  level  of  RF  AGC=0  from  its  current  parent.  This  added  metric 
will  aid  in  determining  the  fitness  of  a  node's  current  parent.  To  ensure  delivery  of  stored  data  packets, 
retransmit  of  a  data  packet  (when  an  acknowledgement  (ACK)  from  the  direct  parent  is  not  received) 
has  been  enabled.  It  will  allow  1  retransmit  attempt.  The  network  transmits  an  ACK  between  the 
originating  node  and  its  immediate  parent.  An  issue  that  may  arise  with  this  functionality  is  when  a 
packet  is  lost  during  some  intermediate  hop.  Since  an  ACK  is  not  issued  when  a  packet  is  received  via  an 
indirect  child,  the  subsequent  parent  down  the  chain-link  will  not  know  that  a  packet  was  not  received 
from  its  grandchild.  If  we  are  to  enable  ACKs  for  all  these  hops,  the  number  of  packets  will  double  and 
since  current  configuration  timing  is  optimized  for  5  nodes,  collisions  may  occur.  Finer  timing  granularity 
to  support  a  higher  node-count  was  envisioned  to  be  advanced  in  the  option  years. 

Under  the  currently  envisioned  evolution,  trainees  would  transmit  their  911  messages  during  their 
assigned  time-slot,  but  could  also  be  transmitted  on  a  randomized  basis  during  a  set-aside  interval.  The 
network  layer  was  configured  to  enable  functionalities  for  the  advancement  of  certain  Option  Year  1 
tasks,  such  as  the  formation  of  multi-squad  and  multi-instructor  network.  The  design  was  aimed  to  form 
two,  separate,  instructor-led  squads,  operating  on  two  separate  network  identification  numbers. 
Support  for  bi-directional  messaging  via  the  repeater  node  between  the  following  node  types: 
TOC/student  and  TOC/instructor,  was  also  perfected.  The  network  layer  was  modified  to  update  the  LCD 
(liquid  crystal  display)  911  messages  to  match  the  state  of  the  911  push  button  of  the  radio  in  order  to 
diminish  any  delay.  The  previous  scheme  was  updating  the  LCD  display  every  30  seconds. 
Enhancements  provided  real-time  update  of  the  LCD  display  with  the  corresponding  911  bi-directional 
push  button  and  messages. 

Additional  assessment  tools  and  command-line-interface  (CLI)  messages  were  added  to  the  code  to  aid 
in  validating  proper  storage  and  operation  of  stored  messages  when  a  node  is  off-network,  as  it  relates 
to  node  de-registration  and  subsequent  re-registration,  packet  queuing  and  buffering.  This  tool  is 
instrumental  in  the  analyses  of  the  CLI  outputs  during  laboratory  and  field  testing,  as  well  as  the 
examination  of  the  CLI  outputs  from  the  demonstration  and  submission  of  the  corresponding 
demonstration  technical  reports. . 

4.1  Integration  of  GPS  1PPS  in  Network  Time  Keeping  Operation 

A  network  time-keeping  capability  was  designed,  implemented  and  tested.  This  feature  is  calibrated  by 
the  GPS  signal  and,  subsequently,  sustains  node-timing  during  periods  of  GPS  outage.  This  provides  a 
period  of  operation  during  which  the  transmission  of  node-  and  network-packets  will  continue, 
counteracting  the  effect  of  intermittent  disruption  of  GPS  communication. 

To  allow  finer  timer  resolution,  individual  network  node  time  was  derived  from  the  1  pulse-per-second 
signal  available  from  the  on-board  GPS  module.  This  allowed  network  timing  synchronization  to  be 
achieved.  The  objective  of  the  time  synchronization  subsystem  was  to  discipline  this  clock  source  to  the 
incoming  1  pulse  per  second  (PPS)  GPS  signal.  The  target  was  to  obtain  a  time  reference  that  provides  a 
highly  stable  source  at  the  required  rate. 
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4.2  New  Managed  Network  Architecture 

In  order  to  make  the  most  effective  use  of  the  available  network  capacity,  the  network-layer  design  was 
incrementally  advanced  to  result  in  an  architecture  that  exhibits  a  high  degree  of  managed-control  that 
is  available  through  the  Tactical  Operations  Center  (TOC).  This  "managed  network"  philosophy  provides 
for  enhanced  performance  by  providing  greater  control  over  system  resources. 

In  the  original  network  architecture,  the  instructor-node  broadcasted  an  invitation  message  and  nodes 
replied  using  an  ALOHA  scheme,  attempting  to  register  on  the  network.  The  random  nature  of  ALOHA 
transmissions  resulted  in  collisions  that  can  slow  the  process  of  receiving  a  time-slot  assignment  and 
registering  with  the  network.  An  improved  methodology  can  be  realized  by  taking  advantage  of  the  fact 
that  the  radios  authorized  to  be  within  a  squad  can  be  pre-assigned  a  time-slot  by  the  TOC.  With  this 
information  available  to  the  instructor's  radio,  the  invitation  message  can  be  made  to  be  more 
information-rich  and  eliminate  collisions  during  the  registration  process. 

In  some  cases,  improvements  made  are  enabled  by  features  of  the  SPARNET  use-scenarios  that 
distinguish  them  from  many  commercial,  network  specifications.  In  particular,  unlike  many  published 
network  standards,  the  SPARNET  system  has  a  priori  knowledge  of  all  nodes  that  are  assigned.  That  is,  at 
the  TOC,  there  exists  a  complete  listing  of  all  radios  (with  associated  identification  numbers)  that  are 
authorized  to  operate  on  the  system.  This  means  that,  during  the  configuration  of  an  instructor's 
handheld  unit,  the  roster  information  required  for  operation  of  the  instructor's  map  application  will 
contain  the  list  of  trainees,  the  identification  numbers  of  the  radios  assigned  to  the  trainees,  along  with 
a  time-slot  assignment  from  a  master  list  of  available  time-slot  resources. 

Under  the  newly  developed  network-layer  implementation  model,  the  previous  invitation  message  has 
been  replaced  with  a  control  message.  The  control  message  contains  the  radio  identification-number  of 
each  radio  within  the  instructor's  squad,  along  with  the  time-slot  that  the  radio  has  been  assigned  by 
the  TOC.  When  this  message  is  broadcasted,  receiving  nodes  will  immediately  discover  their  time-slot 
assignment,  as  well  as  the  radio  identification  numbers  and  time-slots  assigned  to  all  other  radios  within 
the  squad.  Individual  radios  will  complete  their  registration  and  transmission  of  their  first  data-packet 
during  their  assigned  time-slot,  not  using  a  randomly-transmitted  packet  in  response  to  the  invitation 
message. 

The  new  architecture,  based  on  a  priori  knowledge  of  radio  IDs  and  time-slots,  transforms  the 
registration  from  a  probability-based  process  to  a  deterministic  process.  Further,  because  nodes  register 
in  their  own  time-slots,  registration  with  candidate  parents  that  have  temporally-nearby  time-slots  and 
exhibit  adequate  link-energy  can  be  accomplished  more  quickly,  an  important  benefit  when  the  validity 
of  a  signal-strength  assessment  rapidly  declines  with  time.  In  addition  to  providing  pairings  of  time-slots 
and  radio  identification-numbers,  the  control  packet  is  envisioned  to  contain  squad-specific,  network- 
configuration  information.  For  example,  via  the  managed  network  model,  the  payload-length  of  packets 
and  the  hop-depth  might  be  traded  against  each  other  to  permit  larger/smaller  payloads  or 
shallower/deeper  hop-depths. 

Other  uses  for  the  ancillary  information  can  include  signaling  of  trainee  nodes  by  either  the  instructor  or 
the  TOC.  Trainees  who  become  lost  would  be  reported  to  the  TOC.  The  TOC  operator  would  be 
responsible  for  adding  the  time-slot/radio-ID  of  the  lost  trainee  to  the  authorized  squad-member  list 
contained  in  the  handheld  of  TOC-selected  instructors.  This  information  would  be  added  to  the 
broadcasted  control  message  and  repeated  throughout  the  individual  squad  network.  If  the  lost  trainee 
comes  sufficiently  close  to  the  network,  it  would  register  and  this  information  would  be  passed  to  the 
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TOC  and,  via  the  TOC,  to  the  trainee's  instructor.  This  functionality  was  successfully  shown  in 
Demonstration  4,  where  an  off-net  trainee-node  was  recovered  by  a  squad  to  which  it  had  not 
been  previously  assigned. 

4.2.1  New  Network  Creation  Rules 

At  startup,  the  TOC  application  will  initiate  the  network  by  sending  a  roster  over  the  TOC  radio  that  will 
be  used  to  construct  the  TOC's  control  message.  The  network  will  be  initiated  when  the  TOC  radio  is 
powered  up.  The  control  message  is  a  list  of  radio  IDs  of  each  radio  (TOC,  Repeater(s),  Instructor  and 
Students).  Each  radio  will  be  able  to  infer  its  slot  by  its  ID  position  in  this  list. 

•  Repeater  nodes  respond  to  control  messages  sent  by  either  the  TOC  node  or  other  repeater 
nodes  that  are  not  its  children  by  sending  their  data  to  that  node  on  the  repeater  time  slot. 

•  The  Instructor  responds  to  control  messages  sent  by  either  the  TOC  or  any  repeater  node  via 
sending  its  data  to  that  node  on  his  time  slot. 

•  Students  respond  to  control  messages  sent  by  either  the  Instructor  or  any  student  node  that  is 
not  in  their  child  node  table  via  sending  data  to  that  node  on  their  own  time  slot. 

Each  node  will  maintain  a  list  of  potential  candidate  parents  based  on  which  control  messages  it 
received  in  the  most  recent  frame.  From  these  nodes,  it  will  select  the  "best"  parent  based  on  fitness 
metric  that  will  initially  be  an  R.F.  automatic-gain-control  value  but  will  become  more  sophisticated  in 
the  near  future.  "Registering"  is  accomplished  by  sending  data  to  that  parent.  The  node  is  considered  to 
have  an  active  parent  and  will  begin  sending  control  messages  on  its  own  slot,  before  it  sends  its  most 
recent  data  message.  "Registering"  is  accomplished  when  a  node  decides  on  a  parent  based  on 
parameters  set  forth  above.  See  example  below. 

NODE  7  GUID  6666 

[10:22.000]  cur  parent  (0)  last  seen  at  RFAGC=0 
[10:22.008]  parent  is  now  3,  RFAGC  =  6 
[10:22.015]  »DATA 

When  the  potential  parent  receives  a  data  packet  from  a  node,  it  will  add  the  node  to  its 
"childNodeTable",  see  below. 

[10:10.192]  Type=1000  104:103 
[10:10.198]  «Rx  DATA 
[10:10.202]  »send  ACK,  direct  child 

[10:10.208]  Node  4  now  added  to  childNodeTable,  degree  =  0. 

If  a  node  fails  to  receive  a  data  message  from  a  node  that  is  in  its  child  node  table  for  3  consecutive 
frames,  it  will  assume  that  this  node  is  not  a  child  anymore  and  remove  it  from  the  child  node  table.  This 
means  that  this  node  is  now  eligible  to  be  a  parent  node  if  it  sees  a  control  message  from  it. 

If  a  node's  current  parent  metric  gets  too  low  (e.g.  RFAGC  =  0)  it  will  reregister  with  the  best  new 
advertising  parent  it  sees  in  the  most  recent  frame. 
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If  a  node  fails  to  receive  four  acknowledgements  in  a  row  in  the  absence  of  other  advertising  parents,  it 
will  assume  its  current  parent  is  unreliable.  It  will  send  a  deregistration  message  to  its  children  and  begin 
broadcasting  its  data. 

4.3  Bi-directional  Communication 

Enabling  bi-directional  communication  between  the  TOC  node  and  end  nodes  in  the  training  field  was 
achieved  by  producing  an  application  programming  interface  (API).  The  API  lets  information  be  written 
to  be  written  to  the  radio  via  the  communication  (COM)  port.  The  messaging  supports  an 
acknowledgment  packet  that  the  TOC  receives  and  parse  to  determine  if  the  message  was  received  by 
the  student. 

The  basis  for  bi-directional  communication  between  the  TOC  and  end  node  is  highlighted  below.  The 
basic  test  scenario  was  that  a  bi-directional  communication  is  established  when  a  node  initiates  a  911 
event  and  the  TOC  manually  acknowledges  (ACK)  the  911  event.  The  liquid  crystal  display  (LCD)  of  the 
node  will  initially  display  a  "911=OFF".  When  a  node  activates  a  911  event,  the  message  on  the  LCD  will 
change  to  "911=ON"  and  the  corresponding  light  emitting  diode  (LED)  on  the  radio  will  activate  and 
illuminate  red. 

Once  the  TOC  receives  the  911  message  alert  from  the  node,  it  will  transmit  an  ACK  of  the  911  event. 
That  signal  is  sent  over  the  network,  is  received  by  the  target  student  node,  and  that  node's  display  will 
change/update  accordingly.  When  the  node  receives  the  ACK  from  the  TOC,  the  911  message  displayed 
on  its  LCD  will  change  from  "911=ON"  to  "911=ACK".  Since  the  ACK  has  been  received  by  the  node,  it 
will  deactivate  its  911  message  event  by  once  again  pressing  its  911  push  button  to  disable  its  911  state 
and  the  red  LED  on  the  radio  will  turn  off.  The  911  state  in  the  node's  data  packet  will  reflect  that  it  has 
been  deactivated. 

Even  though  the  911  push  button  has  been  pressed  to  turn  off  the  911  state,  the  message  on  the 
student  node's  LCD  will  remain  in  "911=ACK".  The  911  state  in  the  data  packet  will  reflect  that  it  is 
indeed  off.  When  the  TOC  receives  the  message  that  the  911  has  been  turned  off,  it  will  clear  the  bit 
corresponding  to  the  radio's  slot  ID  in  the  control  message.  This  will  cause  the  message  on  the  target 
student's  LCD  to  go  from  "911=ACK"  to  "911=OFF". 

To  satisfy  the  requirement  per  PWS  4v:  demonstrate  bi-directional  TOC  and  student  node  messaging  for 
student  nodes  separated  at  initiation  of  TOC  node  message  event  and  later  reconnected,  the  premise 
activity  was  the  same  as  above.  With  the  target  student  node  off-line  (not  connected  to  the  rest  of  the 
network)  the  TOC  operator  designated  the  target,  and  transmitted  the  signal  as  per  a  911  messaging 
event.  The  TOC  was  aware  that  the  target  node  was  either  off-line  and/or  had  not  received  the 
message,  and  continued  to  attempt  to  deliver  the  trigger  signal  until  the  target  node  re-connected  to 
the  network.  At  that  point,  the  target  node  received  the  trigger  signal  and  actions  highlighted  in  the 
previous  paragraph  were  repeated. 

4.4  Operation  of  Two  Squads  and  Demonstration  of  Recovery  of  Off-net  Student 

The  network  layer  was  configured  to  enable  functionalities  for  the  advancement  of  Option  Year  1  tasks, 
such  as  the  formation  of  multi-squad/multi-instructor  network  and  the  recovery  of  an  off-network 
student  node.  The  design  was  verified  via  the  formation  of  two,  separate,  instructor-led  squads, 
operating  on  two  separate  network  identification  numbers,  using  a  common  R.F.  frequency.  One 
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instructor  was  registered  with  the  TOC  node  and  the  2nd  instructor  was  registered  with  the  repeater 
node.  The  repeater  node  forwarded  the  2nd  instructor  and  its  squad's  data  packets  to  the  TOC  node. 

The  objective  was  to  optimize  the  network  layer  for  the  advancement  of  the  formation  of  two 
instructor-led  training  squads,  operating  from  a  single  TOC  and  auto-configured  to  use  a  single,  R.F. 
frequency.  In  Demonstration  4,  due  to  the  limitations  on  the  number  of  radios,  each  squad  consisted  of 
one  instructor  and  two  students.  The  TOC  application/database  provided  the  capability  to  configure/re¬ 
assign  the  individual  nodes  in  the  separate  training  squads  to  and  from  the  two,  independent  network 
identifications  (id).  This  allowed  the  demonstration  of  the  recovery  of  an  off-network  student  node  in 
which  a  student  node  separated  from  its  originally  assigned  squad. 

As  the  separated  student  node  deregistered  with  its  squad  on  network  id  2,  it  began  broadcasting  its 
data  packet  and  consequently  was  considered  off-network  and  potentially  "lost".  The  TOC  began  a 
discovery/reassignment  activity  by  listing  the  "lost"  student  as  a  member  of  the  first  squad  and  enabling 
the  missing  student  to  register  with  the  first  squad  on  network  id  1,  by  making  and  transmitting  the 
necessary  reassignment  in  the  system  "control"  packet.  The  control  packet  was  communicated  to  the 
instructor  of  the  first  squad,  where  the  control  packet  was  propagated  to  all  registered  nodes  in  the  first 
squad.  As  the  "lost"  student  came  sufficiently  close  to  the  first  squad  to  receive  the  modified  control 
message,  the  "lost"  node  recognized  the  authorization  to  join  and  registered  with  the  first  squad, 
rejoining  the  network.  Using  planned  future  capabilities,  the  student  node  would  be  directed  to  return 
to  his  original  squad,  where  he  would  (via  TOC  command)  be  de-registered  from  the  first  squad  and 
permitted  to  re-register  and  resume  his  training  activities  with  his  original  squad.  Alternatively,  it  could 
be  directed  to  some  other  area  at  the  discretion  of  training  personnel. 

4.5  Develop  Performance-assessment  Software 

To  prepare  for  requirements  set  forth  in  the  Performance  Work  Statement  (PWS)  and  to  fulfill  successful 
demonstrations  criteria  for  base  year  1,  system-performance  measurement-utilities  and  metrics  were 
the  subjects  of  engineering  activities.  Performance-assessment  software  was  developed  to  facilitate  the 
capture  and  storage  of  performance  metrics,  as  required  to  support  demonstrations  and 
characterization  tests.  Exemplar  metrics  that  were  characterized  included:  message  throughput  rate, 
error  rate,  dynamic  configuration  of  network  topology,  and  time  of  registration/re-registration. 

Topologically-based  features  were  added  and  field  sizes  were  optimized  to  allow  for  topology 
information  to  be  displayed  in  the  SPARNET  applications,  as  illustrated  in  Figure  34.  The  architecture 
supports  rendering  of  lines  between  participants.  This  will  force  participant  coloring  and  to  support  off- 
network  participants  to  display  via  TOC  Application.  In  Figure  34  ,  the  time  of  registration  to  the  node's 
respective  parents  are  listed  on  the  top  left  hand  of  the  application. 

Figure  34  illustrates  the  need  for  maps  with  finer  granularity,  when  zooming  in  to  span  short  distances 
on  the  display.  As  can  be  seen,  the  pixels  of  the  digitized  map,  while  still  showing  local,  geographical 
features,  can  become  objectionably  unclear.  The  use  of  map-files  with  higher  resolutions  will  gracefully 
resolve  this  issue.  When  the  display  is  zoomed  out,  the  granular  nature  of  the  current  map-file  is 
negligible  (see  Figure  40). 

As  shown  in  Figure  34,  a  student  icon  is  represented  by  an  isosceles  triangle.  If  green,  then  the  last  data 
packet  received  was  successfully  routed  through  the  instructor.  If  blue,  the  last  packet  received  was 
received  as  a  broadcasted/un-routed  packet  and  was  not  routed  through  the  instructor.  The  number  to 
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the  left  of  the  icon  indicates  its  time  slot.  The  time  slot  corresponds  to  the  time  in  which  the  participant 
transmits  its  control  and  data  packets.  Slots  are  integer  values.  The  number  to  the  right  of  the  icon  is 
that  participant's  parent  slot. 


*  My  I  ■tj*  Sxmrt  TOC  ...  ||  Debug 


|  portw«wio>«...  |  □  Scwmt  Pete 


Figure  34.  TOC  application  main  screen  display 


4.5.1  TOC  Application/Data  Broker  Error  Rate  Calculations 

The  algorithm  that  computes  packet  error  rates  was  reconfigured  so  that  the  algorithm  checks  every 
thirty-second  interval  to  determine  if  one  packet  was  received  and  stored  in  the  TOC  database.  If  no 
packet  was  received  and  stored  in  the  TOC  database  then  this  is  counted  as  a  packet  error. 

A  function  was  created  to  compute  the  "message  error  rate".  A  "message  error"  is  said  to  have 
occurred  if  neither  a  routed  nor  broadcast  packet  from  the  originating-node  is  received  and  stored  in 
the  TOC  database  in  any  given  30-second  interval.  This  is  different  from  a  "packet  error"  in  that  the 
"packet  error"  checks  every  30  second  interval,  but  examines  only  routed  packets  (to  determine  the 
routed  packet  error  rate),  or  broadcast/un-routed  packets  (to  determine  the  un-routed  packet  error 
rate.) 

4.5.1.1  Message  Error  Rate 

The  message  throughput  rate  is  a  calculation  tallied  based  on  the  feedback  regarding  a  separate 
network  study.  In  the  study,  successful  reception  of  any,  routed  or  un-routed,  message  received  at  the 
head-in  was  counted  as  a  successful  message  reception.  The  assumption  is  that  it  does  not  matter  what 
route  the  message  took  to  arrive  at  its  destination,  what  matters  is  the  message  successfully  arrived  at 


Page  54  of  116 


For  Official  Use  Only  (FOUO) 


its  intended  destination.  The  message  error  rate  column,  as  exemplified  in  Figure  40,  represents  this 
assumption.  The  message  error  rate  is  computed  the  same  way  the  packet  error  rate  is  computed. 
Therefore,  as  long  as  the  TOC  received  a  packet  for  any  given  node  (routed  or  un-routed)  within  each 
thirty  second  interval,  then  the  message  error  rate  is  0%. 

4.5.1. 2  Error  Rate  Calculation 

The  error  rates  contained  in  the  submitted  demonstration  technical  reports  were  manually  analyzed  and 
computed.  This  was  accomplished  by  stepping  through  all  the  individual  TOC  Data  Broker  log  and  CLI 
logs  of  the  TOC  node,  repeater  node,  instructor  node  and  trainee  nodes.  For  example,  in  the  TOC  Data 
Broker,  if  there  was  a  missing  data  packet  for  a  specific  node  at  a  specific  time,  within  a  30-second 
frame,  the  repeater  and  the  TOC's  CLIs  were  examined  to  determine  at  which  point  in  the  topology,  the 
data  packet  failed.  At  different  points  in  the  demonstrations,  the  repeater  and  the  TOC's  respective 
distances  from  the  nodes  in  the  field  were  at  close  proximity,  and  with  the  repeater  and  the  TOC's 
antennas,  had  the  capability  to  receive  or  "listen"  to  almost  all  of  the  node's  packet  transmissions.  In 
analyzing  their  individual  CLIs,  one  can  infer  the  path,  where  the  breakdown  of  the  link  occurred.  Once 
that  is  accomplished,  the  log  file  of  the  individual  node  is  examined  to  determine  the  reason  a  particular 
radio's  data  packet  did  not  arrive  at  the  TOC. 

It  is  also  important  to  understand  the  context  of  the  "error  rate"  value  in  the  data  set  that  is  displayed 
on  the  TOC  database/application.  It  is  a  measurement  of  data  packets,  for  each  node,  that  should  be 
received  and  stored  in  the  TOC  database  between  two  specified  times.  As  stated  above,  in  order  to 
determine  the  exact  reason  for  a  particular  radio  error  rate,  the  log  files  from  all  of  the  radios  must  be 
examined. 

The  error  rate  is  a  computed  value  and  is  calculated  by  using  the  following  formula: 

Er  =  l-( (expected  packets  -  received  packets)  /  expected  packets] 

The  expected  number  of  packets  received  from  a  radio  is  an  estimated  value  since  it  cannot  be  certain  at 
any  given  moment  exactly  how  many  packets  should  have  been  received  at  the  TOC.  The  expected 
number  of  packets  received  from  any  given  radio  is  estimated  based  on  the  number  of  times  per  minute 
the  radio  transmits  packets,  as  well  as  the  time  at  which  the  radio  started  transmitting  packets.  Over 
time,  the  error  rate  can  be  assumed  to  be  reasonably  accurate,  assuming  the  radios  were  not  turned  off 
for  some  reason  since  the  TOC  has  no  knowledge  of  the  power  state  of  any  given  radio.  The  error  rate  is 
computed  based  on  the  assumption  that  once  a  radio  has  started  transmitting,  it  should  continue  to 
transmit  in  its  time  slot.  In  addition,  the  error  rate  is  based  upon  a  specified  time  to  begin  estimating 
when  we  expect  to  start  seeing  packets. 

The  calculation  displayed  on  the  TOC  application  is  a  rolling  10-minute  window  that  computes  the  error 
rate.  But  when  a  test  parameter  is  specified,  it  presents  the  error  rate  from  the  beginning  of  the  test  to 
the  current  time.  There  are  occurrences  where  the  error  rate  can  have  a  value  and  revert  back  to  a 
zero  value.  This  can  occur  in  2  cases: 

Use  Case  1:  No  test  is  running  and  the  displayed  routed  packet  error  rate  is  displaying  a  10-minute 
rolling  window.  If  time  is  currently  12:09:31,  the  application  would  look  at  every  30-second  period 
between  12:00:00  and  12:09:30  (20  packets  - 10  minutes). 
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12:00:00  -  packet  received 
12:00:30  -  NO  PACKET  RECEIVED 
12:01:00  - 12:09:30  -  packet  received 

In  this  case,  a  packet  was  not  received  at  12:00:30  but  received  every  other  packet.  This  means  the 
error  rate  would  be: 

(20  expected  packets  - 19  received  packets)  /  (20  expected  packets)  =  1/20  =  5%  error  rate 
Let's  say  for  the  next  1  minute  (2  frames),  the  TOC  received  data  packets. 

12:10:00  - 12:10:30  -  packet  received. 

Now  the  current  time  is  12:10:31,  so  the  rolling  window  the  application  is  looking  at  is  12:01:00  - 
12:10:30.  In  this  case,  the  TOC  has  received  every  packet  during  that  time  period,  and  therefore,  the 
error  rate  would  be  0%. 

Use  Case  2:  Data  collection  is  specified  by  starting  a  test  managed  through  the  Administration  -> 
Monitoring  tab  in  the  TOC  application.  The  time  slot  where  a  packet  is  not  received  never  rolls  out  of 
the  window  for  the  error  rate  calculation  since  there  is  a  definite  start  time.  However,  even  though  a 
rolling  window  is  not  being  used,  it  is  possible  for  the  error  rate  to  rise  above  zero  and  then  drop  to  zero 
again. 

Start  of  Test  at  13:00:00 

13:00:00  - 13:09:30  -  Packets  collected  (20  frames  since  the  start  of  the  test  -  0%  error  rate) 

13:10:00  -  Missed  a  data  packet  (21  frames  since  the  start  of  the  test  - 1/21  packets  missed  =  4.8%  error 
rate) 

13:10:30  -  Missed  a  data  packet  (22  frames  since  the  start  of  the  test  -  2/22  packets  missed  =  9.1%  error 
rate) 

If  the  missed  packets  were  due  to  the  node  being  off  network  and  then  the  node  re-joins  after  13:10:30, 
it  starts  transmitting  its  current  and  store-and-forward  data  packets. 

13:11:00  -  TOC  receives  current  13:11:00  packet  and  the  13:10:00  missed  packet  (23  frames  since  the 
start  of  the  test  - 1/23  packets  missed  =  4.3%  error  rate) 

13:11:30  -  TOC  receives  current  13:11:30  packet  and  the  13:10:30  missed  packet  (24  frames  since  the 
start  of  the  test  -  0/24  packets  missed  =  0%  error  rate) 

4.6  Network  Performance  Estimates 

Foundational  field-test  operations  conducted  during  the  period  being  reported  were  based  on  a 
topology  that  consisted  of:  one  TOC  node,  one  repeater-node,  one  instructor-node  and  five  trainee- 
nodes.  In  order  to  confirm  the  suitability  of  the  design  for  extension  to  a  larger,  more-complex  topology 
analysis  and  simulation  was  conducted. 

During  the  project,  modification  of  the  process  by  which  nodes  register  and  form  the  ad  hoc  network 
was  changed  to  a  Time  Division  Multiple  Access  (TDMA)  approach.  In  TDMA,  each  radio-node  is  assigned 
an  exclusive,  periodically-occurring  time-slot.  By  extending  this  approach  from  the  data-communication 
interval  to  include  the  registration  interval,  the  potential  for  packet-collisions  was  eliminated. 
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The  formation  of  a  network  commences  with  the  transmission  of  configuration  information.  This 
information  provides  the  identification  number  of  each  radio  within  a  squad,  including  that  of  the 
instructor,  along  with  a  unique  time-slot  assignment  for  each  radio.  Upon  reception  of  this  packet,  and 
under  the  assumption  that  the  on-board  Global  Positioning  System  (GPS)  receiver  has  acquired  and 
provided  the  system  time-base,  individual  radios  may  initiate  data-transmissions. 

Verifying  the  extensibility  of  the  design  from  supporting  a  single  instructor  and  five  trainees  to  two 
instructors,  each  with  ten  trainees,  begins  by  calculating  the  number  of  unique  slots  (one  for  each 
participating  radio-node)  required  by  the  new  topology.  Since  there  are  25  radio-nodes  in  the  topology 
under  analysis,  25  unique  slots  are  required. 

The  Spartan  design  philosophy  of  the  network-layer  architecture  requires  that  each  slot  be  sufficiently- 
long  to  allow  communication  over  the  number  of  message-hops  that  are  required  to  deliver  an 
updating-packet  to  the  Tactical  Operations  Center. 

For  example,  under  the  scenario  wherein  the  hop-depth  within  the  Squad  Area  Network  is  constrained 
to  five  hops,  the  network  could  configure  such  that  a  maximum  of  five  hops  would  be  required  to  allow 
an  update-packet  from  the  most  distant  trainee  to  arrive  at  the  instructor-node.  However,  to  arrive  at 
the  TOC-node,  an  additional  three  hops  would  be  needed.  In  total,  the  duration  of  the  assigned  slot- 
length  needs  to  be  sufficient  to  permit  a  total  of  eight  hops,  plus  an  initial  re-transmission  of  the 
configuration  information  by  the  originating  node,  prior  to  sending  its  data  packet. 

The  ability  to  support  any  given  number  of  hops  within  a  single  time-slot  is  a  function  of  the  number  of 
bits  in  a  packet  (two  bits/symbol)  and  the  symbol  rate  used  by  the  SAN  radio.  It  is  important  to  note 
that  because  the  radios  are  software-defined,  with  minimal  modification  it  is  feasible  to  gracefully, 
incrementally  increase  the  symbol  rate  to  at  least  twice  the  current  rate  to  support  additional  message 
traffic,  if  necessary.  But,  for  purposes  of  providing  estimated  performance  based  on  normal  operational 
cases  of  star-  and  linear-topology,  the  symbol  rate  employed  during  the  demonstrations  is  assumed  for 
the  analyses  and  simulations  that  are  reported  in  this  section. 

Under  the  symbol  rate  and  packet  structure  employed  in  the  field  tests,  the  duration  of  a  packet- 
transmission  was  253.6  milliseconds.  So,  the  slot-time  necessary  to  support  a  total  of  nine  packet- 
intervals  is  2282  milliseconds.  Assuming  a  once-per-minute  update  rate,  this  means  that  a  total  of  26 
nodes  can  be  supported,  with  no  change  other  than  a  simple  adjustment  to  the  slot-length  parameter. 

Simulation  scripts  were  written  and  run  to  support  analysis  of  the  two-instructor  topology  called  out  in 
the  Performance  Work  Statement.  The  results  provided,  below,  exclude  the  delay  that  can  be  caused  by 
the  time  required  for  the  GPS  receiver  to  acquire  and  make  available  the  system-time  that  enables  the 
associated  radio  to  transmit.  Based  on  measurements  made  during  field  demonstrations,  the  average 
amount  of  time  required  for  GPS  acquisition  was,  approximately,  30  seconds,  with  170  seconds  being 
the  longest  time  ever  observed,  using  the  integrated  GPS  antenna. 

Under  the  TDMA  protocol  unique  time-slots  are  assigned  to  each  radio  node.  This  means  that  the 
configuration  of  separate  squad-area  networks,  where  the  associated  radio-nodes  are  well  within  radio¬ 
range  of  each  other  and  operating  on  a  common  radio  frequency,  will  occur  without  interference 
between  radio-nodes.  A  two-squad  topology  was  successfully  demonstrated  in  Field  Demonstration  #4 
of  the  project,  with  both  squads  within  radio  range  and  using  a  common  frequency. 
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The  time  required  for  the  network  to  auto-configure  is  a  function  of  a  variety  of  factors  that  can  include: 
topology-type,  slot  order,  update-interval  (where  "update-interval"  (or  frame)  is  the  period  required  for 
the  slot-assignments  for  all  nodes  to  occur  one  time)  and  the  distribution  of  specific  time-slots  within 
the  frame. 

The  simulation  results  provided  were  derived  using  the  bounding  topological  cases  of  the  squad-area 
portion  of  the  overall  network  that  were  approved  and  adopted  for  the  field  demonstrations.  These  are 
the  star-topology,  shown  in  Figure  35,  and  the  five-hop  linear-topology,  shown  as  the  upper-branch  in 
Figure  36.  It  was  assumed  that  the  repeater  network  was  already  formed  at  the  time  that  the  individual 
radios  in  a  squad  are  energized.  Further,  it  was  assumed  that  all  of  the  radios  in  a  squad,  including  the 
instructor's  radio,  were  simultaneously  energized. 

A  range  of  packet-error-rates,  based  on  observations  made  during  demonstrations,  was  used  in 
simulations  to  provide  broader  insight  into  the  effect  of  the  link-quality  on  both  network-configuration 
time  and  network  throughput. 

The  influence  on  network-formation  of  the  association  of  a  particular  slot-assignment  with  a  particular 
trainee-radio  is  not  a  factor  in  a  star  network.  In  all  other  network  configurations  such  associations  can 
influence  the  amount  of  time  required  for  initial  configuration.  The  reason  that  the  association  of  time- 
slots  with  nodes  affects  configuration-time  is  attributable  to  their  order  of  occurrence  within  an  update- 
interval  (frame). 

The  network  layer  operates  by  partitioning  a  frame  into  time-slots.  The  sequenced-occurrence  of  time- 
slots  within  the  frame  begins  with  the  TOC,  followed  by  the  repeaters,  instructor  and  trainees,  in  that 
order.  The  configuration  of  the  network,  following  instructor-registration  with  the  repeater-network, 
begins  with  the  instructor-node  transmitting  configuration  information  that  was  previously  obtained 
from  the  TOC. 

Trainee-nodes  that  are  within  range  of  the  instructor  receive  the  transmitted  configuration-information. 
The  time-slot  that  is  assigned  to  the  radio-identification  number  of  a  receiving  trainee-radio  is  retained 
by  the  radio.  The  radio  monitors  radio  transmissions  from  other  nodes  to  produce  a  list  of  suitable 
parent-nodes.  Following  reception  of  the  configuration  information,  when  the  time-slot  of  a  radio 
occurs  the  radio  will  transmit  its  trainee-data  to  the  parent  that  it  elects. 
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Figure  35.  Star-topology  with  10  trainee-nodes 


Figure  36.  Linear-topology  with  5  trainee-nodes 
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Under  ideal  conditions,  the  most  suitable  parent  would  be  one  that  has  a  time-slot  that  occurs 
immediately  preceding  the  one  assigned  to  the  node  that  wishes  to  transmit.  Candidate-parents  that 
have  a  time-slot  that  is  temporally-close,  preceding  that  of  the  prospective  child-node,  is  assumed  to  be 
more  reliable  than  information  that  was  obtained  during  earlier  transmission  evaluations. 

Figure  37  illustrates  an  ideal  arrangement  of  nodes  for  a  linear  topology  to  be  formed  upon  start-up. 
This  is  because  each  of  the  time-slots  occurs  immediately  following  the  time-slot  of  the  candidate 
parent.  This  association  of  time-slots  with  node  locations  enables  the  fastest  possible  configuration¬ 
time  for  a  linear  topology.  That  is,  the  entire  topology  can  be  formed  within  one  frame  (approximately 
58  seconds,  assuming  once-per-minute  updates). 
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Figure  37.  Slot-ordering  supporting  shortest  configuration-time 

Under  certain  scenarios,  it  can  be  the  case  that  the  most  suitable  parent-node,  in  terms  of  signal- 
strength,  may  have  a  time-slot  that  occurs  after  the  slot  that  has  been  assigned  to  a  prospective  child- 
node.  This  can  slow  the  registration  process,  but  has  no  subsequent  effect  on  the  immediate  relay  and 
arrival  at  the  TOC  of  post-registration  packet-traffic. 

The  most  extreme  case  would  be  in  a  linear  topology  where  the  time-slots  occur  in  descending  order, 
moving  away  from  the  instructor,  are  adjacent  and  located  at  the  end  of  the  frame,  and  the  trainee- 
nodes  are  out-of-range  of  any  nodes  except  their  immediate  neighbors.  The  latter  condition  would 
delay  discovery  by  each  node  of  its  time-slot  assignment.  Such  a  topological  configuration  is  illustrated 
in  Figure  38. 

Assuming  a  25-slot  frame-partition,  in  the  descending-time-slot-order  scenario  the  trainee-node  closest 
to  the  instructor.  Trainee  E,  could  register  within  the  first  frame,  typical  of  trainee-registration  under  a 
star-topology.  Thereafter,  registration  by  Trainee  D  would  be  delayed  by  one  minute  minus  the  number 
of  slots  between  the  beginning  of  its  time-slot  and  the  time-slot  of  Trainee  E.  Similarly,  registration  by 
the  third  trainee-node,  Trainee  C,  would  occur  one  minute  minus  the  interval  between  its  slot  and  the 
slot  of  Trainee  D. 
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Instructor 


Figure  38.  Slot-ordering  imposing  longest  configuration-time 

Assuming  that  the  five  slots  of  Figure  38  were  adjacent  and  occurred  at  the  end  of  a  one-minute  update- 
interval,  and  that  each  node  successfully  registered  on  its  first  attempt,  the  minimum  amount  of  time 
required  for  the  linear  topology  with  descending  slot-order  to  form  would  be,  approximately,  4.7 
minutes,  or  2.35  minutes  if  30-second  updates  were  employed.  (Note,  this  worst-case  slot-arrangement 
was  assumed  for  the  network  simulation  results  reported  in  Table  2.) 

It  should  be  noted  that  the  probability  of  having  a  descending  order  with  each  node  able  only  to 
communicate  with  immediate  neighbors  upon  network  start-up  would  is  small.  The  registration  and 
network-configuration  process  is  certainly  achievable,  but  doesn't  represent  a  practically-occurring 
configuration-initiation  use-scenario,  if  for  no  other  reason  than  the  channel-impairments  (terrain¬ 
blocking,  extended  range)  that  would  have  to  be  present.  For  example,  it  is  unlikely  that  an  instructor 
would  separate  trainees  by  ranges  of  1000  meters  and  only  then  issue  a  command  to  energize  all  radio¬ 
nodes. 

Simulation  was  used  to  obtain  estimates  of  the  number  of  frames  required  to  form  the  bounding  cases 
of  star  and  linear  topologies.  The  squad-area  network  modeled  with  the  star-topology  included  one 
instructor  and  10  trainee-nodes.  The  linear-topology  consisted  of  one  instructor  and  five  trainee-nodes, 
representing  the  maximum  hop-depth  case. 

Two  cases  of  the  linear  topology  were  examined.  In  one,  the  time-slots  were  associated  to  support  the 
shortest  configuration-time,  as  suggested  in  Figure  37.  In  the  other,  the  time-slots  were  associated  to 
impose  the  longest  configuration-time,  using  an  ordering  such  as  that  of  Figure  38.  The  results  for  the 
star  and  linear  topologies  are  provided  in  Table  1  through  Table  3,  below. 

Each  row  of  each  table  contains  the  results  for  10,000  network  initial-configuration  trials.  The  columns 
contain  the  number  of  times  that  the  associated  number  of  frames  (shown  at  the  top  of  the  columns) 
were  required  to  achieve  full  squad-registration,  under  the  overall  packet-error-rate  shown  in  the  left¬ 
most  column. 

For  example,  in  Table  1,  for  an  overall  throughput  of  90%  (10%  error  rate)  observed  at  the  TOC,  in  6285 
of  the  10,000  trials  the  entire  network  of  10  trainees,  arranged  in  a  star,  registered  to  form  the  squad- 
area-network  within  the  first  frame  (update-interval).  Another  3390  of  the  10,000  nodes  registered 
within  the  second  frame.  The  length  of  a  frame  is  dependent  on  how  a  network  is  operated.  While  one- 
minute  is  often  used  as  a  reference,  the  actual  length  of  a  frame  can  be  under  the  control  of  the 
network  operator  and  depends  on  factors  such  as  the  permitted  hop-depth,  total  number  of  nodes 
being  operated  and  the  number  of  available  operating  frequencies. 
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Table  1.  Squad-subscription  completion-frame  (star-topology,  10  trainees) 

Pkt  Err 

Frame  Number 

Rate  (%) 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

6285 

3390 

303 

21 

1 

0 

0 

0 

0 

8 

6936 

2879 

174 

10 

1 

0 

0 

0 

0 

6 

7547 

2343 

107 

3 

0 

0 

0 

0 

0 

4 

8282 

1671 

47 

0 

0 

0 

0 

0 

0 

2 

9183 

807 

9 

1 

0 

0 

0 

0 

0 

Table  2  shows  the  results  obtained  for  the  case  of  a  linear  topology  with  ascending  slot-time  indices, 
such  as  is  shown  in  Figure  37.  As  can  be  seen  by  examining  these  results,  complete  network-formation 
is  possible  within  the  first  frame-interval.  This  reflects  the  fact  that  the  time-slot  of  each  child-node’s 
candidate  parent  occurs  prior  to  the  child-node's  time-slot.  So,  there  is  no  additional  delay  imposed  by 
having  to  wait  until  the  next  frame  to  respond  to  the  transmission  observed  from  the  candidate  parent- 
node. 

Table  2.  Squad-subscription  completion-frame  (linear-topology,  ascending  slot-times) 

Pkt  Err 

Frame  Number 

Rate  (%) 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

7732 

1983 

253 

30 

1 

1 

0 

0 

0 

8 

8138 

1650 

193 

18 

1 

0 

0 

0 

0 

6 

8632 

1256 

105 

5 

2 

0 

0 

0 

0 

4 

9127 

822 

50 

1 

0 

0 

0 

0 

0 

2 

9526 

456 

16 

2 

0 

0 

0 

0 

0 

The  results  of  Table  3  show  the  anticipated  delay  in  commencement  of  network  formation  that  is  caused 
by  the  fact  that  the  time-slots  of  the  parent  nodes  occur  after  the  time-slots  of  the  associated  child 
nodes.  When  a  child  node  first  hears  a  transmission  from  the  prospective  parent,  it  cannot  respond 
until  the  next  time  that  the  child’s  own  time-slot  occurs.  Depending  on  where  the  child’s  slot  occurs 
within  a  frame,  relative  to  the  parent’s  time-slot,  that  time  can  be  up  to  one  full  minute,  minus  one  slot¬ 
time.  For  the  purposes  of  the  bounding-case  simulated  and  reported  in  Table  3,  the  absolute  worst-case 
scenario  was  modeled.  That  is,  the  last  five  time-slots  in  a  frame-interval  were  used  in  the  model.  Note 
that  the  numbers  obtained  for  the  subscription-performance  are  similar  to  those  of  the  ascending-time- 
slot-index  case  (Table  2)  but  are  delayed  in  time  by  five  frames,  as  expected  for  the  descending-time¬ 
slot-index  case. 

Table  3.  Squad-subscription  completion-frame  (linear-topology,  descending  slot-times) 

Pkt  Err 

Frame  Number 

Rate  (%) 

4 

5 

6 

7 

8 

9 

10 

11 

12 

10 

0 

7764 

1940 

261 

32 

3 

0 

0 

0 

8 

0 

8179 

1629 

176 

12 

4 

0 

0 

0 

6 

0 

8615 

1253 

122 

9 

1 

0 

0 

0 

4 

0 

9076 

867 

55 

2 

0 

0 

0 

0 

2 

0 

9533 

462 

5 

0 

0 

0 

0 

0 
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Table  4  shows  the  configuration  results  for  a  five  trainees,  registering  as  a  star,  the  topology  with  no 
dependence  on  the  registration  status  of  other  trainee  nodes. 

Table  4.  Squad-subscription  completion-frame  (star-topology,  five  trainees) 


Pkt  Err 

Frame  Number 

Rate  (%) 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

8108 

1810 

81 

1 

0 

0 

0 

0 

0 

8 

8485 

1467 

48 

0 

0 

0 

0 

0 

0 

6 

8815 

1150 

34 

1 

0 

0 

0  u 

0 

0 

4 

9247 

741 

12 

0 

0 

0 

0 

0 

0 

2 

9631 

364 

5 

0 

0 

0 

0 

0 

0 

Comparison  of  the  simulation  results  shows  that,  with  all  other  things  being  equal,  a  linear  subnet  of 
five-trainees  with  descending  slot-assignments  would  produce  the  dominant  delay  in  forming  a  squad- 
area-network  topology.  That  is,  if  five  nodes  form  a  linear-topology,  while  the  remaining  five  form  a  star 
or  shorter,  branched  sub-networks,  the  five-node  linear-element  is  most  likely  to  be  the  dominant  factor 
in  determining  the  overall  time  required  for  the  entire  10-trainee  network  to  form.  Comparison  of  Table 
1  and  Table  4  provides  insight  into  the  effect  the  number  of  trainees,  registering  in  a  star,  has  on  the 
overall  time  required  for  initial  configuration. 

With  regard  to  network  throughput,  the  addition  of  nodes  that  increase  the  number  of  hops  required  to 
span  the  origin-to-destination  space  will  have  the  net  effect  of  reducing  the  successful  packet-reception 
rate.  That  is,  operating  individual  squads  with  additional  trainees,  while  maintaining  the  hop  depth  to 
be  the  same  as  used  in  prior  work  (five-hops  within  the  squad)  will  not  affect  the  characteristic 
throughput  of  the  system.  This  is  because  the  network  employs  TDMA  protocol,  making  the  statistics  of 
message  throughput  for  one  originating-node  independent  other  nodes.  However,  with  all  other  things 
being  held  equal,  the  incorporation  of  additional  repeaters  in  a  way  that  introduces  additional  hops  to 
the  network  would  have  the  effect  of  reducing  the  successful  packet-reception  rate  for  any  given  squad. 

So,  under  the  scenario  where  the  network  is  expanded  to  take  the  form  of  two,  ten-trainee  squads,  each 
squad  communicating  via  a  unique  repeater  that  links  directly  to  the  TOC  (repeaters  form  a  star- 
topology  with  the  TOC)  the  throughput  performance  would  be  similar  that  documented  during  the  final 
demonstration.  Only  the  case  wherein  the  two  repeaters  form  a  linear  connection  to  the  TOC  will  cause 
a  reduction  in  the  throughput.  Estimates  of  the  effect  are  provided  in  Table  5. 

Table  5.  Estimated  Effect  on  Network  Throughput  by  Additional  Repeater  in  Linear  Repeater  Topology 


Successful  Packet-reception  Rate 

Baseline 

Estimated  { at  Instructor) 

Estimated  (at  TOC) 

(%) 

Star 

Linear 

Star 

Linear 

90 

0.9851 

0.9275 

0.9416 

0.8866 

92 

0.9882 

0.9422 

0.9535 

0.9091 

94 

0.9912 

0.9568 

0.9653 

0.9317 

96 

0.9942 

0.9713 

0.9769 

0.9544 

98 

0.9971 

0.9857 

0.9885 

0.9772 
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In  Table  5,  the  column  titled  "Baseline"  represents  the  successful  packet-reception  rate  from  which  the 
individual,  single-link  statistics  were  calculated.  The  entries  of  the  remaining  columns  show  the 
estimates  of  successful  packet-reception  at  the  instructor-node  and  TOC-node,  under  the  various  cases 
of  single-link  performance.  The  baseline  values  are  exemplar  of  those  observed  in  both  field  and 
laboratory  network  testing. 

In  addition  to  the  time  required  to  initially  form  a  network  and  the  subsequent  probability  of  successful 
packet-reception,  estimated  operational-life  is  a  key  system-characteristic.  Estimation  of  operational- 
life  can  begin  by  noting  that  trainee-  and  instructor-radio  battery-capacity  is  significantly  less  than  that 
of  a  repeater-node  or  the  TOC-node.  That  is,  the  squad-radio  is  the  central  element  of  interest  in 
estimating  network  operational-life. 

In  order  to  provide  a  foundation  for  determining  required  estimates,  a  range  of  single-link  and  five- 
trainee  network-testing  was  executed  to  determine  operational-life  characteristics,  as  currently 
configured.  This  information  was  used  to  generate  the  estimates  that  follow. 

With  the  software  operating  as  it  is  currently  configured,  the  network  operational-life  in  actual  field 
tests  has  been  observed  to  be  in  excess  of  three  hours  when  the  radios  are  operated  exclusively  using 
high-power  transmissions  and  in  excess  of  3  hours  45  minutes  when  operated  exclusively  using  low- 
power  transmissions.  Recently-conducted  single-link  and  five-trainee  network-testing,  aimed  at 
precisely  determining  operational-life,  confirmed  operations  lasting  3  hours  12  minutes  (high-power 
mode)  and  4  hours  (low-power  mode). 

For  purposes  of  estimating  operational-life,  it  is  useful  to  consider  an  exemplar  network  consisting  of 
one  TOC-node,  one  repeater-node,  one  instructor-node  and  five  trainee-nodes.  Such  a  network 
requires  eight  time-slots  per  update-interval. 

It  is  important  to  note  that,  across  all  possible  network  architectures  the  instructor-node  is  the  most 
heavily-burdened,  in  terms  of  transmission  and  reception  activity.  The  amount  of  drain  that  this  activity 
places  on  the  battery  is  a  function  of  both  traffic-volume  and  the  transmission  power-level. 

Other  methods  for  increasing  the  operational  life  of  the  radios,  while  permitting  continuous  operation, 
were  planned  for  Option  Year  1.  Because  a  significant  amount  of  the  power  consumed  by  the  radio  is 
attributable  to  the  continuous  computational  load  imposed  by  the  Blackfin  processor,  large  reductions 
in  power  consumption  can  be  accomplished  by  leveraging  dynamic  power-management  that  provides 
for  control  of  processing-frequencies  and  core  voltage-levels.  In  addition,  five,  standby  power-modes 
are  available  for  use. 

The  use  of  two,  dual-core  processors  on  the  SPARNET  digital  board  offers  the  opportunity  to  partition 
the  software  into  multiple  cores.  This,  in  turn,  allows  the  processing  speed  and  core  voltage  of  any 
given  core  to  be  reduced.  Power  consumption  is  reduced  linearly  with  reductions  in  clock  frequency  and 
as  the  square  of  reductions  in  core  voltage. 

Initial  analysis  shows  that  achieving  a  reduction  in  overall  power  consumption  to  a  level  that  is  between 
one-quarter  and  one-third  of  the  current  consumption  can  be  accomplished  in  the  design  by 
straightforward  means  such  as  code-partitioning  to  enable  reduction  in  processing  speed,  power- 
management  of  peripheral  components  that  are  not  currently  put  in  standby  when  feasible  and  use  of 
processor  standby-modes. 
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For  example,  currently,  all  circuits  operate  continuously.  However,  the  actual  requirement  is  only  that 
selected  circuits  be  operated  during  specific  intervals  within  the  time-slots  that  are  assigned  to  the  TOC, 
instructor  and  other  trainee-nodes  that  are  within  the  same  squad.  Even  in  these  cases,  radios  that 
have  relayed  a  packet  may  be  immediately  placed  in  standby  mode,  once  the  transmission  has  taken 
place.  The  savings  in  power  that  results  from  this  approach  is  topology-specific  but  is  significant. 

Consider  the  network  set  forth  for  analysis  in  5b,  on  page  10  of  the  PWS.  This  is  a  network  consisting  of 
one  TOC-node,  one  repeater-node,  one  instructor-node  and  five  trainee-nodes.  First  of  all,  assuming  a 
partitioning  that  permitted  support  for  26  nodes,  but  in  which  only  8  were  supported,  the  instructor- 
node  could  be  placed  in  standby  for  at  least  17  time-slots,  assuming  the  time  for  one  additional  slot  was 
lost  to  activity  related  to  enabling/disabling  standby-mode  operation.  The  radio  would  effectively  be 
turned  off  for  65%  of  the  update-interval,  increasing  its  operational  life  by,  approximately,  2.9  times. 
Based  on  the  measured  values  reported  above,  this  would  result  in  an  operational-life  of  9  hours  16 
minutes  in  high-power  mode  and  12  hours  when  operating  in  low-power  mode. 

As  previously  described,  additional  savings  can  be  attained  by  making  straightforward  refinements  to 
the  network  layer  software  such  that  a  radio  will  go  into  standby-mode  immediately  after  forwarding  a 
packet. 

For  example,  in  using  a  partitioning  for  26  radios,  but  operating  with  one  repeater,  five  trainees,  and 
depending  on  when  the  packet  to  be  relayed  occurs  within  a  time-slot,  an  instructor-radio  could  be 
turned  off  for  between  22%  (5-trainee  linear  topology)  and  67%  (star-topology)  of  the  packet  interval. 
The  actual  amount  of  time  that  the  radio  could  be  placed  in  standby  is  primarily  a  function  time-slot- 
length,  which  is  a  function  of  factors  such  as:  packet-length,  update-rate,  squad-topology  and  maximum 
hop-depth  from  the  repeater.  The  amount  of  time  required  to  exercise  power-management  features  is 
on  the  order  of  milliseconds  and  can  be  ignored  for  purposes  of  the  estimates  being  discussed,  here. 

It  is  important  to  note  that  the  operational  mode  set  forth  in  the  preceding  paragraph  is  relevant  to 
operation  with  any  number  of  supportable  trainee-radios.  That  is,  the  same  reduction  in  power 
consumption  can  be  realized  across  larger  squads. 

In  the  case  of  a  five-trainee  squad,  an  average  reduction  of  40%  across  the  trainee-node  slot-times 
would  result  in  an  additional  reduction  in  power  of  7.7%,  raising  the  previously-estimated  operational- 
life  values  for  the  high-power  and  low-power  cases  to  11  hours  53  minutes  and  14  hours  51  minutes, 
respectively.  Dynamic  power  control  would  result  in  an  aggregate  operational-life  falling  between  these 
two  limits. 

For  ease  of  explanation,  the  analysis  has  assumed  a  conservative  case  in  which  partitioning  to  support 
26  nodes  is  done  using  slots  of  equal  length.  In  actual  practice,  some  slots  will  be  somewhat  shorter 
than  those  used  for  the  squad-area  radios. 

For  example,  the  TOC-node  is  not  involved  in  lengthy  relay  activities.  So,  the  remaining  time  that  would 
otherwise  have  been  allocated  to  the  TOC  under  a  uniform-slot-length  model  can  be  used  for  other 
purposes  or  aggregated  with  similar  savings  from  repeaters  to  enable  an  additional  slot  or  otherwise 
contribute  to  minimizing  power-consumption. 
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4.7  Modification  of  SAN  Network  Software  for  Repeater-node  Application 

To  facilitate  training  over  a  more  expansive  geographical  area,  a  network  of  stationary  repeater  nodes 
can  be  placed  to  create  a  lengthened  communications  backbone  to  relay  participant  node-information 
as  presented  by  the  various  instructor  nodes.  These  repeater  nodes  are  capable  of  transmitting  over 
greater  distances  and  are  not  constrained  by  the  lower  power  requirements  of  the  wearable  radios.  For 
all  but  the  smallest  training  scenarios,  participant  information  is  relayed  from  the  instructor  to  the  TOC 
via  at  least  one  Repeater  node.  This  was  the  premise  executed  in  Demonstration  4  performed  on 
February  02,  2012. 

Due  to  the  volume  of  data  that  must  be  transmitted  over  this  backbone,  the  timeliness  of  the  student 
data  updates  and  the  transmit  range  of  the  repeater  radio(s);  the  repeater  network  can  be  configured  to 
use  a  different  operating  frequency  than  the  instructor  gateway  network. 

Data  intervals  on  the  repeater  network  are  longer  than  data  intervals  on  the  individual  gateway 
networks  since  there  are  likely  fewer  repeater  nodes  and  each  is  responsible  for  relaying  much  larger 
amounts  of  data.  In  the  same  way  as  DATA  packets  in  the  squad-area  networks  multi-hop  during  the 
data  interval  of  the  terminating  node,  the  data  packets  relayed  from  each  child  gateway  node  are 
concatenated,  transmitted  and  retransmitted  by  the  Repeater  network  during  the  data  interval  of  the 
repeater  node  for  which  those  gateways  are  children. 

The  repeater  network  software  was  developed  using  the  squad-area  software  as  a  foundation.  Like  the 
individual  gateway  networks,  the  repeater  network  is  self-configuring.  The  TOC  node  will  act  as  the 
gateway  of  the  repeater  network  and  be  responsible  for  sending  invitations  to  both  other  repeater 
nodes  and  gateway  nodes.  In  this  network,  gateway  nodes  do  not  rebroadcast  this  invitation  -  only 
repeater  nodes  can  extend  invitations  to  register  on  the  repeater  network.  Registration  on  the  repeater 
network  follows  the  same  protocols  that  trainee  end  nodes  use  to  register  with  the  squad-area  gateway 
network.  Additionally,  the  design  is  envisioned  to  allow  the  TOC  operator  to  interrogate  the  repeater 
backbone  for  information  on  student-nodes.  In  cases  where  a  student-node  has  unexpectedly  fallen  off 
of  the  squad-area  network,  the  Instructor  may  request  that  the  TOC  locate  and  report  the  student-node 
position. 

4.8  Store  and  Forward  Capability 

For  the  squad-area  network,  a  store-and-forward  capability  was  introduced  to  satisfy  the  PWS 
requirement  set  forth  to  be  executed  in  Demonstrations  2-4.  In  the  event  that  a  student  node  exceeds 
the  radio  range  of  the  Ranger  Instructor's  gateway  node,  and  for  some  defined  period  of  time  is  out  of 
radio  contact  (as  indicated  by  a  failure  to  receive  data  acknowledgement  packets),  the  student's  SAN 
radio  will  locally  store  all  pertinent  sensor  data  for  the  absence  period  and  then  forward  this  to  the 
Gateway  node  upon  resumption  of  communication  and  registration  back  in  to  the  network. 

If  and  when  a  node  receives  four  network  acknowledgement  (ACK)  failures  or  receives  a  deregistration 
packet  from  its  parent,  the  store-and-forward  functionality  will  commence.  It  will  begin  storing  its  data 
packet  in  a  buffer  that  will  increment  and  store  additional  packets,  as  long  as  the  node  is  off-network  or 
unregistered.  Once  the  node  registers  with  a  suitable  parent,  it  will  begin  transmitting  its  current  data 
packet  followed  by  the  transmission  of  a  store-and  forward  packet.  It  will  continue  in  this  mode  until  all 
the  store-and-forward  packets  in  its  queue  have  been  transmitted.  To  ensure  delivery  of  stored  data 
packets,  retransmission  of  a  data  packet  (when  an  acknowledgement  (ACK)  from  the  direct  parent  was 
not  received)  was  enabled.  It  allows  one  retransmit  attempt.  The  network  transmits  an  ACK  between 
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the  originating  node  and  its  immediate  parent.  An  issue  that  may  arise  with  this  functionality  is  when  a 
packet  is  lost  during  some  intermediate  hop.  Since  an  ACK  is  not  issued  when  a  packet  is  received  via  an 
indirect  child,  the  subsequent  parent  down  the  link-chain  will  not  know  that  a  packet  was  not  received 
from  its  grandchild.  If  we  are  to  enable  ACKs  for  all  these  hops,  the  number  of  packets  will  double  and 
since  current  configuration  timing  is  optimized  for  five  nodes,  collisions  may  occur.  Finer  timing 
granularity  to  support  a  higher  node-count  can  be  advanced.  The  detailed  operation  of  such  network 
features  are  application-specific  and  can  be  conveniently  programmed  to  best  support  individual  use- 
scenarios. 

The  SPARNET  network-layer  architecture  facilitates  expedited  re-registration  of  child-nodes  via  a  "de- 
registration"  message  that  is  immediately  transmitted  by  the  parent-node,  when  it  becomes  separated 
from  the  network  and  is  no  longer  a  viable  communication  path  for  message-traffic  from  its  dependent 
nodes  (children,  grandchildren...).  The  de-registration  message  causes  all  of  the  parent-node's 
dependent-nodes  to  immediately  abandon  transmissions  to  their  respective,  former  parents,  seek  new 
parents  and,  where  appropriate,  commence  storage  of  packets  for  subsequent  forwarding  upon  re¬ 
registration.  This  design  reduces  network  complexity,  conserves  battery  power  and  eliminates 
unnecessary  spectral  activity. 

From  the  perspective  of  timely  re-registration  and  data -transfer,  this  design  is  more  efficient  under  the 
unique  operational-requirements  and  constraints  of  the  SPARNET  system.  Accordingly,  subnet 
operation  is  intentionally  not  supported  by  the  SPARNET  network-layer  and  was  not  demonstrated. 
However,  the  independent  separation  and  independent  rejoining  of  nodes  is  consistent  with  the  more 
appropriate  model  and  was  demonstrated  for  cases  in  which  nodes  that  have  rejoined  the  network  and 
are  forwarding  data  will  operate  as  a  parent-  (branch)  and/or  a  child-node  (leaf). 

In  order  to  join  or  rejoin  the  network,  a  node  must  connect  to  a  parent  node.  This  means  that  a 
separated  node  will  always,  initially,  rejoin  as  a  child  (leaf)  node.  After  joining  the  network,  it  is  eligible 
to  act  as  a  parent  to  other  nodes.  The  requirement  set  forth  in  PWS  2e  was  demonstrated  by 
simultaneously  separating  two  nodes  for  a  period  of  10  minutes  and  then  causing  them  to  sequentially 
rejoin  the  network.  The  first  to  rejoin  will  enter  as  a  leaf.  The  second  to  rejoin  will  be  caused  to  rejoin 
with  the  first  that  rejoined,  becoming  its  child  and  transforming  it  to  a  parent  (branch-node). 

The  principle  of  store-and-forward  functionality  is  highlighted  below. 

•  Each  student  maintains  a  circular  buffer  of  the  last  30  minutes  worth  of  DATA  messages. 

•  In  the  event  of  a  re-registration,  the  current  behavior  is  to  assume  that  the  node  has  been  off- 
network  for  some  time,  and  will  begin  sending  all  stored  DATA  messages  in  the  store-and- 
forward  queue. 

•  These  messages  are  sent  one  per  frame  in  the  second  half  of  the  student's  time  slot,  following 
the  most  recent  update. 

•  Parent  Node  Table 

-  Each  student  will  maintain  a  list  of  all  candidate  parent  nodes  based  on  which  control 
message  it  receives.  Filtered  RSSI  values  for  each  of  these  candidate  parents  will  be 
maintained,  so  that  they  can  be  compared  with  the  filtered  value  of  the  current  parent. 
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•  DEREGISTRATION  Packets 

-  DEREGISTRATION  packets  are  used  in  two  cases: 

•  If  a  student  discovers  a  new  candidate  parent  with  a  better  fitness  metric  than 
its  current  parent,  it  will  send  a  DEREGISTRATION  message  to  its  current  parent 
while  the  link  is  still  available.  This  will  cause  the  parent  to  immediately  remove 
the  child  from  its  Child  Node  Table,  rather  than  deleting  it  after  a  timeout. 

•  If  a  student  discovers  its  current  parent  is  unreliable  and  no  new  parent  is 
available  it  will  send  a  DEREGISTRATION  message  to  all  of  its  children.  This  will 
signal  them  to  acquire  a  new  parent  whenever  possible. 

Future  enhancements  may  include: 

•  Parent  Fitness 

-  Combined  metrics  for  parent  node  fitness  will  be  evaluated,  which  may  include  network 
degree  (i.e.  distance  from  instructor),  bottlenecks  (i.e.  the  maximum  number  of  child 
nodes  supported  or  minimum  battery  level  reported  by  any  direct  or  indirect  parent  en 
route  to  the  Instructor)  and  signal  strength. 

•  Smarter  store-and-forward 

-  Through  the  use  of  deregistration  packets,  we  should  have  more  confidence  that  a 
packet  sent  to  our  parent  and  acknowledged  was  routed  to  the  Instructor.  These 
packets  will  not  need  to  be  maintained  in  the  store-and-forward  database. 

A  packet  visualization  feature  was  also  integrated  for  the  display  of  received  routed,  un-routed  and 
broadcast  packets  for  any  particular  node,  as  represented  in  Figure  39. 

Packets  for  Smith,  J.  xj 

(•  Al  Packets  C  Forwarded  Only  W  Routed  l*  Unrouted 


Figure  39.  Routed,  un-routed  and  broadcast  packet  visualization 
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5  Application  Research  and  Development 

The  TOC  and  Instructor  handheld  software  applications  were  enhanced  and  adapted  to  support  an 
increasing  number  of  Soldiers  and  training  venues.  Work  to  eliminate  the  use  of  random  transmissions 
during  network-formation  was  advanced.  This  was  part  of  the  foundational  work  executed  to  increase 
the  capabilities  of  the  TOC  in  managing  the  use  of  the  communication  resources  and  overall  network. 

A  solid  base  of  requirements  was  established  that  defined  the  detailed  functionality  needed  to  field  the 
TOC  Workstation  application.  Plotting  of  TOC  position  based  on  the  geo-location  of  the  TOC-node 
repeater  and  administration/configuration  capabilities  were  researched  and  developed.  TOC 
Workstation  software  modifications  were  completed  to  support  store  and  forward  and  the  display  of 
packets  collected  when  a  node  is  off  the  network.  This  also  involved  modifications  to  the  Data  Broker 
software  and  underlying  database  code.  TOC  Workstation  software  modifications  in  preparation  for  the 
four  demonstrations  set  forth  for  base  year  1  were  executed. 

The  instructor's  handheld  application  was  migrated  from  the  personal  digital  assistant  (PDA)  and  in  to 
the  Microsoft  Windows  Tablet  platform.  Handheld  speech  functionality  was  incorporated  and  available 
for  Demonstration  4. 

Improvements  to  map  rendering  was  executed.  An  issue  that  was  discovered  during  field  testing  in 
preparation  for  the  August  2010  demonstration,  where  the  instructor  and  student  icons  experienced 
rendering  issue  when  zooming  in/out  on  the  map.  The  collapse/expansion  of  the  map  was  causing  the 
locations  of  the  icons  to  move.  Through  rigorous  testing,  the  issue  was  found  and  corrected  on  the 
SparnetMapCreator  and  patches  were  applied  to  the  mapping  functionality  and  to  the  mapping 
applications  of  the  TOC  and  instructor's  mobile  device  software. 

5.1  Icons  Jumping  in  Map  Application  and  GPS  Acquisition  Time 

The  root  cause  of  icons  occasionally,  temporarily  jumping  from  the  appropriate  map  location  was 
investigated.  A  conference  call  between  Elintrix  engineers  and  the  GPS  module  manufacturer,  Trimble, 
was  conducted.  The  conference  call  provided  valuable  insights  to  the  GPS  module  and  the  proprietary 
and  non-proprietary  protocols  that  are  available  for  the  GPS  receiver.  The  principal  issue  in  this 
behavior  involves  the  strength  of  the  received  signal  which,  in  large  part,  is  dependent  on  the  antenna 
gain.  A  larger,  or  external,  GPS  antenna  (which  the  current  design  supports)  may  be  advisable. 

5.2  TOC  Application/Data  Broker 

Work  to  perfect  certain  various  functional  elements  was  performed  on  the  TOC  application  in 
preparation  for  the  demonstrations.  Enhancements  were  executed  to  enable  all  four  demonstrations  of 
functional  requirements,  such  as  bi-directional  communication  between  the  TOC  and  nodes  in  the 
training  field,  reporting  and  visualization  of  heart  rate  data  of  trainee  nodes,  importing  and  exporting 
capabilities,  and  advancement  of  administrative  configurations.  User  interface  for  the  display  of  the 
"message  error  rate"  calculation  was  integrated  in  the  main  display  and  Monitoring  tab  of  the  TOC 
application. 
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The  capability  for  the  TOC  application  to  prepare  for  formation  of  the  network  by  sending  a  roster  to  the 
TOC  radio  that  is  used  to  construct  the  TOC  control  message  and  transmit  it  over  the  air,  was  completed, 
integrated  and  tested.  As  previously  stated,  the  control  message  is  a  list  of  radio  IDs  of  each  radio  (TOC, 
Repeater(s),  Instructor  and  Students),  where  each  radio  will  be  able  to  infer  its  slot  by  its  ID  position  in 
this  list.  This  work  enabled  the  ability  for  the  TOC  radio/application  to  program  radio-slot  assignments 
on  the  field.  The  capability  to  add  a  repeater  node  to  the  exercise  was  also  finished.  Modification  to  the 
TOC  Workstation  software  to  support  collection,  storage,  and  geographic  display-  update  of  the  TOC's 
geographic  location  was  completed. 

Modification  in  the  error  rate  calculations  such  that  "disabled"  radios  are  not  included  in  the  error  rate 
calculation  was  accomplished.  An  equipment  list  to  facilitate  the  tracking  of  the  Zephyr  BioHarness  3 
heart  rate  modules  was  finalized.  Various  enhancements  were  executed  to  enable  Demonstration  4 
functional  requirements,  including  the  capability  to  import  hardware  information.  Modifications  were 
executed  to  allow  the  TOC  application  to  transmit  an  acknowledgement  (ACK)  of  911  alerts  to  individual 
radios,  to  demonstrate  bi-directional  communication  between  the  TOC  and  student  node  and  between 
the  TOC  and  instructor  node.  The  ability  for  the  TOC  application  to  re-assign  radios  to  any  desired  slot 
or  network  id's,  allowing  any  radio  to  be  re-assigned  to  any  instructor  or  squad,  was  added.  A  bug  that 
affected  the  correct  coloring  of  icons  based  on  the  alert  status  or  conditions  was  fixed.  Other  bug  fixes 
were  applied  to  the  TOC  application/database,  correcting  initialization  issues  concerning  the 
transmission  of  the  911  acknowledgement  to  the  student  node,  as  well  as  expanding  the  context  menu 
in  the  application  map-control  to  provide  ample  access  to  the  boundary  box  for  the  icons  on  the  map. 

The  map  control  was  updated  to  display  a  repeater  node  icon  on  the  TOC/Handheld  application,  as  well 
as  an  updated  TOC  icon.  An  interface  was  implemented  to  send  outbound  messages  to  the  map  control 
in  support  of  bi-directional  communication.  A  ruler  function  was  integrated  in  the  map  control  for  both 
the  TOC  and  instructor's  handheld  applications.  This  function  will  allow  the  user  of  the  application  to 
click  and  drag  between  2  points  on  the  map  to  acquire  the  distance,  in  meters.  Rendering  of  the  TOC 
and  repeater  icons  were  augmented  to  allow  the  topology  lines  to  emanate  from  the  TOC  to  the 
repeater  and  from  the  repeater  the  instructor.  This  will  demonstrate  network  self-configuration  with  the 
TOC  as  a  root  and  the  repeater  as  a  branch.  Other  enhancements  to  the  map  control  include: 

•  zoom  in/out 

•  focus  on  participant  or  student  by  roster  number 

•  show/hide  labels 

•  switch  between  views  and  close  the  application 

5.3  Improved  Administration  and  Configuration  Capabilities 

Under  this  task,  the  TOC  user's  ability  to  set  preferences  such  as  passwords  and  display  characteristics, 
security  administration  capability,  processing  and  storage  or  routed  and  un-routed  packets,  processing 
and  storage  of  additional  packet  elements,  management,  monitoring  and  visualization  of  packet  error 
rates,  as  well  as  management,  analysis  and  visualization  of  data  was  advanced.  Enhancements  include: 

•  Implemented  features  relating  to  management,  visualization,  and  analysis  of  packet  error  data. 

•  Implemented  User  security  administration  capabilities. 

•  Implemented  time  synchronization  of  TOC  Workstation  system  clock  with  connected  GPS. 

•  Implemented  security  administration  capability. 
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•  Incorporated  query  of  TOC  GPS  to  retrieve  the  time  and  position  of  the  GPS  attached  to  the  TOC 
workstation. 

•  Synchronization  of  the  TOC  Workstation  system  clock  with  the  attached  GPS  time. 

•  Incorporated  processing  and  storage  of  routed  and  un-routed  packets. 

•  Incorporated  processing  and  storage  of  additional  packet  data  elements  (slot  ID,  parent  slot  ID, 
and  parent  registration  time. 

•  Management,  monitoring,  and  visualization  of  packet  error  rates. 

5.3.1  TOC  Application  Main  Display 

The  TOC  main  display  screen  is  presented  to  the  user  when  the  TOC  Workstation  software  starts,  as 
illustrated  in  Figure  40.  It  provides  the  user  the  ability  to  monitor  any  and  all  exercises  currently  in 
progress.  It  is  used  by  the  coordinating  authority  of  the  training  operation  and  is  used  to  monitor  the 
movement  and  status  of  all  squads  of  trainees  and  their  instructors  and  repeaters.  The  TOC  Application 
runs  on  a  laptop  PC  that  is  physically  connected  to  either  the  root  node  of  the  Repeater  Network  or  to 
the  Ranger  Instructor's  SPARNET  radio  for  single-squad  training  scenarios. 


Figure  40.  TOC  Application  Main  Display 

Below  is  the  legend  describing  the  TOC  Software's  map  icons  and  coloring  scheme. 
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TOC  Icon  -  The  TOC  icon  is  represented  as 
a  blue  square.  The  icon  always  remains 
blue  and  is  positioned  on  the  map  based 
on  the  position  collected  from  the  TOC 
radio's  GPS. 

Topology  Spray  Lines  —  The  lines  radiating 
from  the  TOC  connect  with  other 
instructor  or  repeater  icons. 


Repeater  Icon  -  The  repeater  icon  is 
represented  as  a  blue  equilateral 
triangle.  The  icon  is  always  blue  and 
is  positioned  on  the  map  based  on 
the  position  collected  from  the 
Repeater  radio's  GPS. 

Icon  Label  -  When  left-clicked  on 
any  icon,  it  will  display  a  tool  tip  label  that  displays  the  roster  number,  the  name  of  the  participant,  the 
heart  rate,  the  MGRS  geo-positional  data,  the  distance  in  meters  from  the  instructor,  and  the  bearing  to 
the  instructor.  In  the  case  of  the  repeater,  there  is  an  arbitrary  roster  number  assigned  for  purposes  of 
demonstration  and  testing,  but  this  is  not  required. 


Repeater 

Icon 

Icon  Label 

RN8  (REPEATER,  N.)  HR:0  A 

1 1 S  MQ79640290C5 

70  m  at  110* 

^AiiP 

Slot 


Student  Icon  -  Last  packet 
received  is  routed  through 
instructor. 

>  Parent  Slot 


4 


Student  Icon  -  Last  packet 
received  is  unrouted. 


Student  Icon  -  The  student  icon  is  represented  by 
an  isosceles  triangle.  If  green,  then  the  last  data 
packet  received  was  successfully  routed  through 
the  instructor.  If  blue,  the  last  packet  received 
was  received  as  a  broadcasted/un-routed  packet 
and  was  not  routed  through  the  instructor.  The 
number  to  the  left  of  the  icon  indicates  the  time 
slot  in  which  the  participant  transmits  data.  Slots 
are  integer  values.  The  number  to  the  right  of  the 
icon  is  that  participant's  parent  slot. 


Instructor  Icon  -  The  instructor  icon  is 
represented  by  a  gray  colored  arrow 
shaped  icon. 
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Alerting  thresholds  may  be  configured  by  the  TOC  Application  operator  such  that  when  a  warning 
threshold  or  critical  threshold  is  exceeded,  the  operator  is  notified  by  the  icon  associated  with  the  alert 
changing  colors.  Thresholds  that  may  be  set  include: 

1.  When  a  student  is  more  than  a  specified  distance  from  their  instructor. 

2.  When  a  participant  (student/instructor)  has  not  moved  for  more  than  a  specified  period  of  time. 
(Note  a  lack  of  movement  is  defined  as  no  deviation  in  geographic  position  of  more  than  10 
meters.) 

3.  When  a  participant  has  not  received  any  routed  packets  for  more  than  a  specified  period  of 
time. 

Both  "warning"  levels  and  "critical"  alerting  thresholds  may  be  set.  For  example,  the  operator  may  want 
to  know  when  any  student  is  more  than  100  meters  from  their  instructor.  This  may  be  set  up  as  a 
warning  threshold.  The  operator  may  also  want  to  set  a  critical  threshold  be  set  so  they  are  notified 
when  any  student  is  more  than  700  meters  from  their  instructor.  If  the  student  strays  to  more  than  100 
meters  from  their  instructor  then  a  warning  alert  is  fired  resulting  in  icons  changing  to  a  yellow  color.  If 
the  students  strays  more  than  700  meters,  then  a  critical  alert  is  fired  resulting  in  icons  changing  to  a  red 
color. 


Warning 

*-.£57° 


A  yellow  icon  indicates  a  warning  threshold  has  been  exceeded. 


Alert/911 


A  red  icon  indicates  an  alerting  critical  threshold  has  been  exceeded.  It  may 
also  indicate  that  a  participant  has  activated  their  911  emergency  push 
button. 


TOC  Application  Roster  Listing 


Class 

Roster# 

Hydration  JnL) 

Heart  Rate 

Postion 

Battery 

Rado  ID 

Co/Pt/Sq 

Status 

Pkt 

Rec 

Rate 

Msg  Rec 
Rate 

Last  Updated 

Class  3 

9 

0 

12 

25965.-5722 

90 

21845 

4pha/1st/1* 

OK 

90 

90 

02/01/2012 1324  26 

|  Class  3 

I6 

1° 

!  25959.-5721 

90 

26214 

Alpha/lst/lst 

OK 

1“ 

90 

1 02/01/2012  13:24:22 

The  TOC  Application's  roster  listing  is  displayed  on  the  TOC  Application's  main  page  and  contains  the 
following  data  elements  for  each  exercise  participant: 

•  Class -The  class  number 

•  Roster  #:  The  roster  number 

•  Roster  list  displays  computed/estimated  error  rate  data  for  each  radio. 

•  Hydration  -  Fluid  intake  in  mL.  Currently  displays  a  value  of  0  as  the  exact  implementation  of 
this  feature  is  to  be  determined. 
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•  Heart  Rate  -  Displays  the  heart  rate  captured.  A  value  of  "12"  is  displayed  as  a  default  value  if 
no  heart  rate  is  captured. 

•  Position  -  The  geographic  position  in  MGRS  format. 

•  Battery  -  The  battery  level.  Currently  displays  a  value  of  "90"  as  the  exact  implementation  of 
this  feature  is  to  be  determined. 

•  Radio  ID  -  The  unique  ID  of  the  radio  assigned  to  the  exercise  participant. 

•  Co/PI/Sq  -  The  company/platoon/squad  of  the  exercise  participant. 

•  Status  -  The  current  alert  status.  This  contains  a  description  of  any  warning  or  critical  alert 
raised  for  the  specified  participant.  For  example  if  a  student  has  pressed  their  "911"  button,  the 
status  will  indicate  this. 

•  Pkt  Rec  Rate  -  The  packet  reception/error  rate.  This  is  the  rate  at  which  the  TOC  has  not  stored 
(error)  data  packets  from  each  participant  in  the  TOC  database.  If  a  manually  invoked  test  has 
been  started,  this  will  show  the  reception  rate  from  the  beginning  of  the  test.  If  no  test  has 
been  invoked  then  this  shows  the  reception  rate  over  the  last  10  minutes  (10  minute  rolling 
window.)  The  rate  is  calculated  by  the  following  formula: 

Pe  =  The  number  of  time  slices  expected  to  receive  a  routed  packet  over  the  desired  time  period 
(e.g..  If  we  should  receive  2  routed  packets  per  minute  and  we  look  over  10  minutes,  then  there 
should  be  2  *  10  =  20  time  slices  where  we  expect  to  receive  a  packet.) 

Pr  =  The  number  of  time  slices  where  we  actually  receive  a  routed  packet  over  the  desired  time 
period.  E  =  The  Packet  Reception/error  Rate  displayed  in  the  roster  listing 

E  =  (Pe-Pr)/Pe 

•  Msg  Rec  Rate  -  The  message  reception/error  rate.  This  is  the  rate  at  which  the  TOC  received 
neither  a  routed  or  un-routed/broadcast  packet  in  each  time  slice  over  a  given  time  period. 
Within  a  given  time  slice;  the  TOC  should  receive  one  routed  packet  and  at  least  one  un- 
routed/broadcast  packet  for  each  radio.  For  example,  if  the  system  is  set  to  have  2  time  slices 
(30  seconds  per  slice),  per  minute,  then  there  are  2*10  =  20  time  slices  where  we  expect  to 
receive  one  routed  packet  and  at  least  one  broadcast  packet  per  slice,  if  we  were  to  miss  both  a 
routed  and  broadcast  packet  during  one  of  the  20  time  slices,  the  Msg  Reception/Error  Rate 
would  be  1/20  =  5%.  The  rate  is  calculated  by: 

Me  =  The  number  of  time  slices  expected  to  receive  either  a  routed  or  un-routed  packet 
(message). 

Mr  =  The  number  of  time  slices  where  we  actually  receive  a  routed  or  broadcast  packet 
(message)  over  the  desired  time  period. 

E  =  The  message  reception/error  rateE  =  (Me-Mr)/Me 
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•  Last  Updated  -  The  date/time  the  last  routed  packet  or  broadcast  packet  was  received  by  the 
TOC. 

5.3.2  Security  Administration 

The  TOC  user's  ability  to  set  preferences  such  as  passwords  and  display  characteristics,  as  well  as  to 
access  better  configuration  capabilities  was  increased.  Security  specifications,  user  authentications, 
new  security  class,  AES  encryption/decryption  methods,  deployed  database  tables,  stored  procedure 
code  to  support  management  of  TOC  users  and  roles  to  be  used  within  the  application  were 
implemented. 

Improvements  associated  with  log-in  identification,  roles,  security  management  and  user  password- 
validation  were  made.  Implementation  of  the  TOC  (Tactical  Operations  Center)  Application  user 
administration  screen  was  completed.  This  feature  will  allow  "administrators"  to  create/manage/delete 
TOC  Application  users,  as  well  as  assign  passwords  and  assign  the  proper  security  level  to  each  user. 

The  secure  login  capability  to  the  TOC  Application  is  indicated  below.  Users  are  authenticated  through  a 
login  screen,  per  image  below. 


Username  ff 


Password  | 


OK  |  Cancel 


Figure  41.  TOC  User  Login 


Login/authentication 

-  Three  chances  to  authenticate  before  application  closes 

-  Passwords  stored  in  the  database  using  one-way  MD5  hashing  algorithm  using  Electronic  Codebook 
(ECB)  block  ciphering. 

-  Three  Security  Roles 

•  Admin 

•  Privileged 

•  Basic 
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Loggng  |  Setbng*  S*a»»y  |  Moraonno  | 


ADMIN  (Admimstr  a  tor  Account) 


SMITHJ  (Smith,  John) 
JOHNSONA  (Johnson,  Andrew) 


□ 


UMmame  |  P>— word  | 

fir*  Name  |Accour«  Gr+Med  | 

Last  Name  |MfrwTistr*7"  ”  Modfod  | 

Level  |  ADMIN  j[] 


Delete  User  I  New  Ueer  I  Save 


Close 


Figure  42.  Security  administration  window 

-  Administrator  may  create,  delete,  or  modify  a  TOC  user. 

-  Only  users  defined  through  the  TOC  Security  Administration  component  may  use  the  application. 

5.3.3  Performance-assessment  Capabilities 

Performance-assessment  features  to  provide  for  the  capture,  storage  and  display  of  performance 
metrics,  as  required  to  support  the  demonstrations  and  characterization  tests  were  implemented.  The 
mapping  software  was  modified  to  display  the  children  of  each  parent  node.  This  permits  the  current 
topology  to  be  determined  from  the  map  screen.  Display  improvements  were  advanced  to  allow 
comparison  of  packet-reception  via  the  instructor  and  via  direct  observation  of  trainee  nodes.  Other 
enhancements  include  the  addition  of  slot  assignments  for  all  field  nodes.  The  characterization  activities 
conducted  using  these  enhancements  included:  message  delivery  rate,  time  required  for 
configuration/reconfiguration  and  adaptation  to  different  topologies.  Modifications  to  the  TOC 
application  main  screen  to  display  network  packet-error-rate  were  completed.  This  feature  allows 
graphing/charting  capability  to  display  time-series  graphs  of  packet-  error-rate.  The  TOC  application 
system  time  was  synchronized  to  the  GPS  signal  to  allow  a  single  time  reference  for  time  stamp  analysis. 
Modifications  to  the  Data  Broker  software  included  new  packet  definition  that  stores  the  registration 
and  re-registration  times  with  a  parent  for  each  node. 

Other  improvements  to  the  application  includes  the  ability  to  recall  old  tests  and  meta-data  to  view 
previously  run  tests  along  with  the  time  series  graphs  showing  any  error  rates,  as  exemplified  in  Figure 
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43.  This  function  is  able  to  display  routed  and  un-routed  packet  statistics.  The  ability  to  display  time 
series  error  rates  of  individual  radios  was  also  implemented. 
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Figure  43.  Recall  of  old  test  data  and  associated  packet  error  rate  of  individual  nodes 


Figure  44.  Time  series  graph  of  test  error  rate  statistics 
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The  capability  to  save  the  time  series  graphs  was  incorporated.  As  illustrated  in  Figure  44,  right  click  of 
the  mouse  will  present  the  user  with  various  selections  available  for  the  time  series  graph,  such  as 
saving,  printing  and  other  configurations. 


Figure  45.  Time  series  graphs  -  save  and  print  options 
5.3.4  Sensor  Information 

TOC  Workstation  software  modifications  to  support  the  reporting  of  heart  rate  information  from  the 
Zephyr/POLAR  Bluetooth  modules  were  completed.  This  involved  modifications  to  the  Data  Broker 
software,  application  and  underlying  database  code. 

Heart  rate  tracking  and  plotting  on  a  time  series  graph  was  implemented.  Heart  rate  data  was  included 
in  the  data  packet  and  in  SparnetCore/SparnetMapControl. 

The  path  was  tested  from  an  instructor  radio  to  the  handheld  over  Bluetooth  and  observed  a  heart  rate 
value  on  the  instructor's  personal  digital  assistant  (PDA)  and  subsequently  to  the  Windows  Tablet. 
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Figure  46.  Heart  rate  plots  for  individual  nodes 
5.3.5  Playback  Capability 

The  ability  to  play  back  training  exercises  from  the  TOC  application-software  collected  data  was 
advanced.  When  completed,  this  functionality  will  allow  the  user  to  playback  any  exercise  stored  in  the 
database.  Although  the  user  interface  for  this  functionality  has  been  integrated  in  the  TOC  application, 
as  illustrated  in  Figure  47,  the  utility  requires  additional  work  to  enable  its  full  operation.  This  feature, 
along  with  the  ability  to  view  raw  log  information,  is  envisioned  to  be  provided  as  a  standard  capability. 
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Figure  47.  TOC  playback  user  interface 
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5.3.6  Log  Utility  Analyzer 

Work  on  the  "Log  Analyzer",  a  utility  to  aid  in  post-test  analysis  of  CLI  and  Data  Broker  log-files  was 
advanced.  A  log-analysis  utility  was  developed  for  processing  all  command  line  interface  (CLI)  log  files 
generated  by  the  individual  radios  as  well  as  the  TOC  Data  Broker  log  file.  The  utility  aimed  at  producing 
summary  results  that  are  based  on  the  data  contained  within  the  log  files  and  the  inter-relationships 
between  the  contents.  This  will  allow  the  user  to  trace  each  packet  through,  from  its  origination  to  its 
destination. 
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5.4  Instructor  Handheld  Application 

The  Mapping  Control,  which  is  central  to  both  the  TOC  and  the  Instructor's  mapping  applications,  was 
expanded  to  provide  graphical  information  and  alerts  from  a  variety  of  new  status  indicators  for  each 
participant,  including  but  not  limited  to  geo-location,  heart  rate  data  and  topology  shifts. 

An  extension  of  the  handheld  interface  to  allow  for  bi-directional  communication  including  downloading 
the  roster  to  the  radio  was  integrated  and  tested.  This  modification  was  made  to  provide  capability  for 
the  instructor's  mobile  device  to  send  the  roster  data  it  received  from  the  TOC,  such  as  slot  assignments, 
personnel  information,  radio  and  network  id,  to  the  instructor  assigned  SAN  radio,  where  the 
information  is  parsed  for  retransmission  in  control  messages  transmitted  to  student  nodes. 

Modifications  to  support  the  new  registration  scheme  and  outbound  messaging  were  made. 
Preliminary  message  processing  for  incoming  handheld  messages  in  the  radio  was  added,  as  was  an 
application  programming  interface  (API)  in  SparnetMapControl  to  send  an  outbound  message  from  the 
Tablet/PDA/TOC  PC. 

Enhancements  to  the  instructor's  mapping  application  were  executed  in  order  to  port  the  application 
from  the  PDA  to  the  Tablet. 

The  main  screen  of  the  instructors  map  application  is  shown  in  Figure  48,  with  a  screen  shot  of  a  roster 
shown  in  Figure  49.  Figure  48  is  a  screen  shot  of  simulated  data  on  the  Instructor's  Tablet  mapping 
application.  When  left-clicked  on  any  icon,  it  will  display  a  tool  tip  label  that  displays  the  roster  number, 
the  name  of  the  participant,  the  heart  rate,  the  MGRS  geo-positional  data,  the  distance  in  meters  from 
the  instructor,  and  the  bearing  to  the  instructor.  For  a  detailed  description  of  map  icons  and  coloring 
schemes,  see  Section  5.3.1.  The  distance  and  bearing  from  the  instructor  is  an  important  tool  that  can 
be  utilized  when  a  student  is  in  need  of  assistance.  The  TOC  operator  can  also  set  an  alerting  threshold 
that  will  notify  the  operator  if  any  student  has  exceeded  a  pre-determined  distance  from  the  instructor. 
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Figure  48.  Instructor's  map  application  main  screen  display  (Tablet) 
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Figure  49.  Roster  screen  shot  of  instructor's  mapping  device 
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5.4.1  Purpose-built  PDA  Application  for  Bluetooth-enabled  Sensor 

To  satisfy  the  criteria  of  the  Demonstration  3  requirements  under  PWS  paragraph  3(f):  Demonstrate 
direct  l-PAN  connection  between  on-body  sensor(s)  and  the  Instructor  Node,  bypassing  the  Student 
Node,  a  purpose-built  PDA  application  which  allowed  the  instructor  node  to  directly  link  to  a  student- 
node  sensor  to  monitor  its  heart  rate  was  developed. 

The  connectivity  is  obtained  by  first  turning  off  the  student's  radio  to  break  the  Bluetooth  link  between 
it  and  the  student's  heart-rate  sensor.  Next,  the  PDA  formed  a  link  to  the  student's  heart-rate  sensor 
and  displayed  the  reading  on  the  purpose-built  software  application,  running  on  the  PDA.  The  most 
current  heart-rate  value  received  from  the  sensor  would  be  displayed. 

The  purpose-built  application  on  the  PDA  had  connectivity  problems  with  associating  with  the  student's 
POLAR  heart-rate  sensors  during  the  execution  of  Demonstration  3.  One  of  the  issues  was  due  to  the 
termination  of  the  link  between  the  Bluetooth  that  resided  on  the  PDA  and  the  Bluetooth-enabled  heart 
rate  POLAR  sensor.  The  connectivity  did  not  always  terminate  from  the  previous  sensor  connection  and 
consequently  interrupted  the  new  connection  the  PDA  was  attempting  to  make  with  the  next  student- 
node  in  line. 

Accordingly,  the  PDAs  were  replaced  with  10"  Tablets  (operating  with  Windows)  to  allow  real-time 
observation  of  command-line-interface  (CLI)  messages,  link-quality  and  node-performance.  Other  issues 
arose  from  transitioning  from  the  PDA  to  the  Tablet;  however  the  principal  issue  was  in  the  purpose- 
built  application.  The  application  intermittently  was  reading  from  the  incorrect  Bluetooth 
communication  port.  Migrating  to  the  Zephyr  heart  rate  monitors  and  implementing  the  use  of  their 
BioGauge  application  software  resolved  these  issues  and  was  validated  in  the  execution  of 
Demonstration  4. 

5.4.2  Handheld  Speech 

Elintrix  personnel  collaborated  with  the  author  of  Handheld  Speech  to  successfully  integrate  its 
components  in  to  the  Handheld  map-control  application.  The  author  provided  the  essential  desktop 
project  and  binaries  for  the  recognition  engine  and  source  code  to  enable  Elintrix  staff  members  to 
integrate.  Elintrix  provided  a  desktop  map  application  test  program  of  the  instructor's  map  application 
to  allow  them  to  demonstrate  voice  activated  switching  between  a  communications  application  and  a 
mapping  application.  Separate  and  collaborative  efforts  were  made  to  debug  the  respective 
applications,  such  as  glitches  in  enrollment  and  loading  aspects  of  the  Handheld  Speech  code.  At 
Elintrix,  enhancements  were  added  for  support  of  several  voice  commands  (zoom  in/out,  show  map, 
show  roster,  show  options).  Additional  work  was  completed  in  order  to  enable  the  Handheld  Speech 
application  to  run  on  the  instructor's  PDA  and  later  on  the  Tablet. 

The  author  had  also  set  up  the  application  to  perform  multi-part  voice  commands,  as  in  "zoom  to  radio" 
(part  1)  followed  by  an  index  (part  2).  The  communication  application  that  was  provided  could  be  used 
for  outgoing  voice  commands  from  the  TOC  PC.  They  also  provided  the  source  code  for  the  text-to- 
voice  component  which  would  go  in  the  SAN  radio.  It  converts  phonemes  to  a  .wav  file. 

6  Analysis  and  Reporting  of  Network  Performance 

Analysis  and  reporting  of  the  results  of  demonstrations  and  performance-data  were  executed. 
Laboratory  testing  of  system  elements  was  ongoing.  In  preparation  for  the  four  required 
demonstrations  and  an  interim  December  demonstration  that  occurred  prior  to  the  performance  of 
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Demonstration  4,  extensive  indoor  and  outdoor  testing  of  radios  in  Network  Mode  and  Test  Packet 
Mode  to  improve  and  optimize  radio  performance  was  performed.  They  were  achieved  by  using  over- 
the-air  (OTA)  Network  Testing  in  effort  to  identify  issues  in  the  software  code  and  optimize 
performance. 

Radio  logs  were  accumulated  at  each  test  occurrence  and  analyzed  for  the  purpose  of 
identifying/resolving  issues  and  to  optimize  performance  in  preparation  for  the  demonstrations,  and  to 
validate  overall  radio  system  operation  and  behavior.  Extensive  field-testing  was  conducted  to  obtain 
test-data,  validate  enhancements  and  perfective  work,  and  to  validate  and  rehearse  the  test  plans  for  all 
demonstrations. 

The  Performance  Work  Statement  (PWS)  for  U.S.  Army  contract  number  W911QY_11-C- 
0012  "Integrated  Short  Range,  Low  Bandwidth,  Wearable  Communications  Networking  Technologies" 
sets  forth  specific  demonstration  and  reporting  requirements.  Test  plans  were  established  that  detailed 
the  activities  that  were  conducted  in  the  field  and  in  the  laboratory  to  show  that  the  performance- 
objectives  associated  with  the  four  scheduled  demonstrations  for  the  Spartan  network  (SPARNET)  were 
achieved.  The  aim  of  the  test  plan  documentation  was  to  define  the  methodologies  whereby  the 
intended  characterization  of  performance  was  achieved  in  a  feasible  manner. 

All  four  demonstrations  were  conducted  at  Marian  Bear  Memorial  Park  in  San  Diego,  California. 

6.1  Interpreting  the  Analyses 

The  number  of  nodes  that  can  be  supported  by  the  network  layer  is  scalable  and  configurable.  For  the 
tests  reported  in  this  document  for  Demonstrations  1-3,  the  network-layer  was  configured  to  support 
one  TOC,  one  instructor  and  five  student-nodes,  with  reporting  updates  at  a  rate  of  twice  per  minute. 
For  the  tests  reported  for  the  December  Demonstration,  the  network-layer  was  configured  to  support 
one  TOC,  one  repeater,  one  instructor  and  five  student-nodes,  with  reporting  updates  at  a  rate  of  twice 
per  minute.  For  the  tests  reported  for  Demonstration  4,  the  network-layer  was  configured  to  support 
one  TOC,  one  repeater,  one  instructor  and  five  student-nodes  during  one  part  of  the  test.  The  latter 
portion,  the  network  was  configured  to  support  one  TOC,  one  repeater,  two  instructors,  and  five 
student-nodes,  with  reporting  updates  at  a  rate  of  twice  per  minute. 

Nodes  are  defined  in  the  first  column  of  Table  6  (Section  6.3.2)  in  terms  of  GUIDs  (radio-specific  serial 
numbers)  and  node-assignments,  where  the  node  number  corresponds  to  the  time-slot  assigned  to  the 
particular  radio.  Under  the  new  managed  network  scheme,  the  TOC  operator  designates  the  node  slot 
assignments  for  the  trainees  in  the  exercise  by  composing  the  control  message  that  the  TOC  transmits 
and  propagates  to  the  repeater  and  instructor  nodes.  In  other  words,  the  time  slots  for  the  trainees  are 
static  from  the  onset  of  the  exercise.  However,  the  TOC  has  the  capability  to  dynamically  reassign  slot 
assignments  and  configure  the  squads,  as  necessary,  for  any  given  node  during  the  exercise. 

Anticipated  routed  packet-receptions  correspond  to  the  total  number  of  routed  data-packets  that  the 
Tactical  Operations  Center  (TOC)  application/database  is  expected  to  receive,  based  on  the  twice-per- 
minute  update  rate.  For  instance,  if  the  data  collection  duration  was  for  5  minutes,  the  number  of 
anticipated  routed  packet  receptions  would  be  equal  to  10. 

Error-count  is  the  number  of  instances  where  the  TOC  did  not  receive  a  routed  data  packet  through  the 
instructor  or  the  repeater  for  each  node  in  the  exercise.  The  number  of  un-routed  packets  is  not  being 
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calculated  due  to  its  complexity.  Because  the  TOC  node  can  receive  packets  from  the  surrounding  nodes 
due  to  its  more  sensitive  antenna,  calculating  the  un-routed,  anticipated  packet  receptions  for  the  TOC 
node  is  challenging.  In  the  case  of  the  star  topology,  the  number  of  un-routed  packets  received  by  the 
TOC  is  equivalent  to  the  number  of  anticipated  routed  packet  receptions.  However,  in  topologies  that 
are  more  complex  than  the  star  topology,  the  calculation  must  be  conducted  by  analyzing  the  packet¬ 
hopping  sequences  and  number  of  packets  originated  by  each  node.  The  calculation  can  be  imperfect 
since,  even  though  the  TOC  may  be  within  distance  of  receiving  a  node's  transmission,  the  signal  may  be 
too  low  to  receive.  This  will  impact  the  PER,  which  in  the  case  stated  above,  the  error  may  be 
legitimate. 

A  range  of  error-detection  mechanisms  are  built  into  the  radio  algorithms,  to  aid  in  detecting,  analyzing 
and  resolving  performance  issues.  These  mechanisms  can  detect  issues  such  as  failure  to  properly 
decode  the  packet  (manifested  as  cyclic-redundancy-check,  CRC,  errors),  failure  to  resolve  ambiguity 
that  is  a  normal  part  of  the  synchronization  process  in  quadrature  receivers  and  failure  to  properly 
achieve  phase-synchronization  in  a  timely  manner  ("preamble"  errors).  Under  normal  operation,  these 
types  of  errors  can  be  expected  to  occur  when  the  received  signal  has  been  excessively  degraded  by  the 
channel. 

The  PER  calculation  is  the  percent  of  cases  in  which  the  TOC  application  did  not  receive  an  expected, 
routed  packet  for  a  node  during  the  data  collection  period.  For  example,  the  TOC  did  not  receive  one 
data  packet  out  of  the  anticipated  10  for  GUID  2222.  This  error  count  equates  to  a  10%  PER. 

6.1.1  Message  Throughput  Rate 

The  message  throughput  rate  is  a  calculation  tallied  based  on  the  feedback  regarding  a  separate 
network  study.  In  the  study,  successful  reception  of  any,  routed  or  un-routed  message  received  at  the 
TOC  application/database  was  counted  as  a  successful  message  reception.  The  assumption  is  that  it 
does  not  matter  what  route  the  message  took  to  arrive  at  its  destination,  what  matters  is  the  message 
successfully  arrived  at  its  intended  destination. 

The  message  throughput  rate  column  in  Table  6  represents  this  assumption.  The  message  throughput 
rate  is  computed  the  same  way  the  PER  is  computed.  Therefore,  as  long  as  the  TOC  received  a  packet 
for  any  given  node  (routed  or  un-routed)  within  each  thirty  second  interval,  then  the  message 
throughput  rate  is  100%. 

The  Anticipated  Packet  Receptions  (Un-routed/Routed)  column  displays  the  number  of  un-routed  or 
routed  data  packet  that  was  received  for  the  node  during  the  data  collection  period,  and  that  directly 
corresponds  with  the  calculation  for  the  message  throughput  rate  column.  The  anticipated  packet- 
receptions  (un-routed/routed)  correspond  to  the  total  number  of  un-routed  or  routed  data-packets  that 
the  Tactical  Operations  Center  (TOC)  application/database  is  expected  to  receive,  based  on  the  twice- 
per-minute  and/or  once-a-minute  update  rate.  For  instance,  if  the  data  collection  duration  was  for  5 
minutes,  the  number  of  anticipated  routed  packet  receptions  would  be  equal  to  10  for  the  twice-a- 
minute  (30-second  period)  calculation  and  5  for  the  once-a-minute  (60-second  period)  calculation.  In 
short,  for  this  column,  if  the  TOC  receives  both  an  un-routed  and  routed  data  packets  for  a  node  in  a 
single  frame,  30-second  or  60-second,  it  will  only  count  as  1  since  the  message  throughput  rate  is 
calculated  as  a  successful  reception  of  any,  routed  or  un-routed  message  received. 
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6.2  Demonstration  1  Results 

The  execution  of  month-4  Demonstration  1  was  first  attempted  on  April  28,  2011.  Successful 
demonstration  was  prevented  by  an  anomaly,  the  manifestation  of  which  was  first  noticed  in  field 
testing  of  the  integrated  system.  In  follow-up  laboratory  testing,  it  was  observed  that  transmitters 
sometimes  abruptly  began  producing  distorted  outputs,  significantly  hindering  successful 
communication  with  receiving  nodes.  The  distortion  was  observed  to  be  random  and  appeared  to  be 
more  frequently-occurring  on  some  boards.  Initially,  the  problem  was  thought  to  be  in  the  differential 
amplifier  that  drives  the  modulator  integrated-circuit.  However,  subsequent  to  the  demonstration,  the 
problem  was  observed  as  distortion  that  occurred  earlier  in  the  analog  signal-chain,  in  circuitry  that 
resides  on  the  digital  CCA,  not  the  RF  CCA.  Through  investigative  work,  testing  and  collaboration  with 
DAC  experts  at  Analog  Devices,  resolution  to  the  distortion  issue  was  achieved.  This  issue  was  resolved 
by  adding  small  capacitors  between  the  input  pin  of  the  digital-to-analog  converter  (DAC)  and  ground. 
This  improved  the  signal-integrity  of  the  DAC  output  and  eliminated  the  problem.  As  previously 
mentioned,  the  first  attempt  at  executing  Demonstration  1  was  held  on  April  28,  2011.  It  is  worth 
noting  that  Elintrix  received  permission  to  radiate  on  April  01,  2011.  The  reiteration  of  Demonstration  1 
was  executed  on  July  21,  2011.  The  timeline  for  the  executions  of  the  demonstrations  was  re¬ 
established  to  account  for  the  delay  in  acquiring  the  permission  to  radiate,  which  prevented  acquisition 
of  results  from  tests  conducted  in  the  outdoor  environment.  Below  are  the  subsections  that  identified 
the  issues  experienced  during  the  demonstration  and/or  during  study  of  the  recorded  activity  logs. 

Demonstration  1  was  performed  on  21  July  2011  at  Marian  Bear  Memorial  Park  in  San  Diego,  California. 
A  technical  report  and  a  disc  comprised  of  the  final  technical  report,  log-file  activities  and  other 
accompanying  files  were  submitted  to  the  customer. 

The  subsections  that  follow  discuss  issues  that  were  identified  during  Demonstration  1  and 
subsequently  corrected.  These  issues  were  no  longer  present  during  the  operations  of  Demonstration  2 
and  Demonstration  3. 

6.2.1  Packet  Errors 

Following  the  completion  of  a  software-utility,  the  cause  of  elevated  packet-error-rates  was  successful 
traced  to  a  sporadically-occurring,  anomalous  behavior  in  the  automatic-gain-control  (AGC)  algorithm. 
Investigation  focused  on  the  analog  automatic-gain-control  revealed  that  the  attack-rate  (adjustment 
speed)  was  inadequate.  The  attack-rate  was  adjusted  and  reduced  the  associated  packet-error-rate. 
The  AGC  was  optimized  to  reduce  the  receive  sub-buffer  size  to  improve  the  R.F.  AGC  attack  time.  The 
current  scheme  operates  making  adjustments  in  6  dB  steps,  as  opposed  to  the  previously-employed  2.5 
dB  steps. 

In  addition  to  the  improvements  in  attack-rate,  remnants  of  code  thought  removed  in  earlier  work  were 
found  to  have  been  overlooked.  The  redundant  code  was  removed,  resulting  in  a  significant 
improvement  in  the  packet-error-rate. 

6.2.2  Packet-detection  Issue 

In  reviewing  logs  recorded  during  the  demonstration,  instances  were  observed  wherein  a  radio  would 
randomly  miss  detection  of  packet-energy  and  did  not  process  the  buffered  samples.  This  problem  was 
observed  to  variably  affect  radios,  but  most  specifically  and  severely  affected  the  node  selected  to  serve 
as  the  instructor  node,  thus  having  a  significant  effect  on  the  logged  packet-error-rate  performance  of 
the  overall  system.  The  packet-detection  issue  was  caused  by  improperly  terminated  chip-select  lines 
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associated  with  a  SPI  bus.  This  caused  the  digital-to-analog  converter  (DAC)  that  controls  the  automatic- 
gain-control-variable-gain-amplifier  to  be  randomly  set  to  an  inappropriate  setting,  causing  it  to  be 
placed  in  a  maximum-attenuation  state.  Instances  were  observed  wherein  a  radio  randomly  missed 
detection  of  packet-energy  and  did  not  process  the  buffered  samples.  This  problem  may  also  have  been 
exacerbated  by  the  code  remnants,  described  in  6.1.1.  Corrective  actions  eliminated  the  issue. 

6.2.3  Network  Registration 

Conditions  in  which  incomplete  registration  exchanges  between  a  prospective  child  and  its  candidate 
parent  result  in  an  inaccurate  child-node  table  at  the  parent  node  were  identified  through  analysis  of 
the  demonstration  logs.  The  code  was  modified  to  eliminate  this  bug  for  the  execution  of 
Demonstration  2  and  Demonstration  3.  The  removal  of  the  ALOHA  registration  scheme  and  the 
integration  of  the  managed  network  architecture  for  Demonstration  4  has  rendered  this  issue  moot. 

6.2.4  Measurements 

Measurements  were  made  on  actual  hardware  to  acquire  estimates  of  power  consumed  across  the  set 
of  inter-node  communications.  Antenna  pattern-characterization  testing  was  conducted.  Field 
measurements  made  to  determine  best-,  intermediate-  and  worst-case  orientations  for  the  rubber- 
ducky  and  body-worn  antenna  units.  Measurements  were  made  to  obtain  the  power-consumption 
characteristics  of  the  radio,  across  various  packet-types  during  transmission  and  reception.  Results  of 
the  measurements  were  incorporated  into  the  demonstration  technical  report  submitted  to  the 
customer. 

6.3  Demonstration  2  and  Demonstration  3  Field  and  Laboratory  Results 

Demonstration  2  was  performed  on  Thursday,  October  27,  2011.  Demonstration  3  was  executed  the 
following  day,  Friday,  October  28,  2011.  Demonstration  2  and  Demonstration  3  were  conducted  as 
completely-separate  efforts,  even  though  various  demonstration  requirements  for  Demonstration  3 
were  previously  exercised  during  Demonstration  2.  The  squad-area-network  (SAN)  radio  code-revision 
used  in  both  demonstrations  was  identical.  Performance  similarities  and  issues  cited  in  the  two 
technical  reports  were  attributable  to  the  common  code-revision.  Identical  issues  appeared  during  the 
two-day  presentation,  as  the  heart  rate  monitoring  units  were  integrated  for  Demonstration  2,  as  well 
as  Demonstration  3.  The  link  between  the  use  of  the  heart  rate  monitors  and  the  issues  that  were 
experienced  are  detailed,  in  the  following  sections. 

Work  was  advanced  to  implement  the  various  functionalities  to  facilitate  a  successful  Demonstration  2. 
Store-and-forward  architecture  and  re-registration  algorithms  were  advanced.  De-registration  of  nodes 
was  optimized,  as  well  as  transmission  of  child-report  messages  to  inform  the  previous  parent  of 
registration  with  a  new  parent.  Integration  of  Liquid-crystal-display  (LCD)  to  show  relevant  radio  node 
metrics  was  achieved.  The  display  of  geo-location  and  identification  of  each  node  as  iconic  information 
overlaid  on  a  displayed  map  at  both  the  instructor  node  and  TOC  node  was  verified. 

Concurrent  foundational  work  was  advanced  to  support  Demonstration  3  and  implement  month-9 
functionalities  such  as,  design  of  a  Bluetooth  option-card,  integration  of  POLAR  heart  rate  monitor  units 
and  enhanced  911-message  transmission.  Work  to  incorporate  the  reporting  and  display  of  the 
trainee's  heart  rate  in  the  network,  as  well,  as,  the  TOC  application/database  and  instructor's  mobile 
devices  was  progressed. 
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6.3.1  System  Reliability  during  Demonstration  2  and  Demonstration  3 

Certain  issues  were  experienced  during  the  demonstrations.  These  issues  negatively  affected  the 
system's  ability  to  maintain  the  intended  network  topologies.  It  also  impacted  the  time  it  took  to  form 
the  topologies,  as  nodes  that  experienced  the  problems  had  to  be  turned  off  and,  then,  on  to  clear  the 
problem.  Power  cycling  was  a  temporary  fix  to  reset  the  code.  When  this  occurred,  time  was  consumed 
to  re-acquire  a  GPS  lock  and  to  re-register  with  the  previous  parent  in  order  to  reestablish  the  target 
topology. 

Following  the  demonstrations,  the  engineering  team  focused  on  resolving  issues  that  produced  system 
instability  during  Demonstration  2  and  Demonstration  3.  Experimental  work  revealed  that  the 
introduction  of  Bluetooth-enabled  heart-rate  monitoring  resulted  in  the  unexpected,  randomly- 
occurring  issues  with  radios,  during  the  demonstrations. 

The  team  worked  aggressively  to  diagnose  the  exact  problem  and  arrive  at  a  resolution  in  an  expeditious 
manner.  Lab  testing  of  the  radios  revealed  that  when  the  Bluetooth-enabled  heart-rate  monitors  were 
integrated  into  the  system,  the  radio  operation  would  "lock-up".  In  other  words,  the  code  was  halting 
radio  operation  when  the  heart-rate  modules  were  active.  Therefore,  in  previous  field  testing  of  the 
system,  which  was  conducted  prior  to  the  addition  of  the  heart-rate  monitor  code,  the  lock-up  anomaly 
did  not  occur. 

It  was  discovered  that  recycling  the  power  of  the  radio  unit  would  temporarily  eliminate  the  problem, 
but  it  would  eventually  reasserted  itself,  again.  Vendor  representatives  were  contacted  for  feedback 
and  support  in  the  matter,  instituting  a  parallel  effort  between  the  factory  and  the  engineers. 

Subsequently,  Elintrix  engineers  diagnosed  the  issue  as  being  related  to  the  serial  peripheral  interface 
(SPI)  communication  between  the  MSP430  and  Blackfin  processors.  Corrective  changes  were  made  to 
the  code  and  extensive  lab-  and  field-testing  were  conducted  to  obtain  data  to  validate  enhancements 
and  corrective  work  applied  to  the  code.  Proper  operation  was  confirmed. 

Issues  experienced  with  the  TOC  application  during  the  demonstrations  were  traced  back  to  the 
Windows  7  operating  system  (OS).  Elintrix  has  two  laptops  in  use,  one  with  Microsoft  (Redmond,  WA) 
XP  OS  and  the  other  with  Windows  7  OS.  The  TOC  laptop  with  the  XP  operating  system  has  been  mainly 
used  in  all  the  testing,  up  until  the  last  week  leading  to  Demonstration  2  and  Demonstration  3.  An 
internal  decision  to  change  laptops  prior  to  the  demonstrations  was  ill-advised.  The  main  reason  for 
doing  so  was  to  have  the  better  screen-resolution  provided  by  the  Windows  7  OS  unit.  The  Windows  7 
laptop  has  been  mainly  used  for  development  of  the  application  and  database. 

During  detailed  analysis  of  data  collected  on  the  TOC  Data  Broker,  it  was  discovered  that  a  certain 
number  of  data  packets  were  malformed.  The  TOC  radio  node  accurately  received  the  data  packets  from 
the  surrounding  nodes,  as  verified  using  the  TOC  radio's  command-line-interface  (CLI).  So,  the 
malformed  packet  was  not  a  radio-reception  issue.  The  malformed  packet  issue  was  happening  when 
the  TOC  radio  communicates  the  received  data  packet  via  the  serial-port  cable  to  the  Data  Broker, 
where  the  data  is  then  fed  into  the  TOC  map  application.  This  issue  contributes  to  a  higher  packet  error 
rate,  as  calculated  on  the  TOC  application.  This  is  because  the  Data  Broker  cannot  decipher  the 
distorted  data-packet  messages  that  are  used  to  update  the  TOC  application. 
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The  malformed  packet  issue  experienced  during  Demonstration  2  and  Demonstration  3  was  corrected. 
The  malformed  packets  occurred  when  the  TOC  radio  communicated  the  received  data  packet  via  the 
serial-port  cable  to  the  Data  Broker,  where  the  data  was  then  fed  into  the  TOC  map  application.  This 
issue  contributes  to  a  higher  packet  error  rate,  as  calculated  on  the  TOC  application.  This  is  because  the 
Data  Broker  cannot  decipher  the  distorted  data-packet  messages  that  are  used  to  update  the  TOC 
application.  The  basic  fix  was  to  implement  a  circular  buffer  to  send  the  handheld  packets  from  the  TOC 
radio.  The  original  buffering  scheme  that  was  implemented  was  not  circular  and  was  overwriting  the 
buffer  every  time  a  packet  was  to  be  transmitted.  If  a  packet  was  queued  and  a  new  packet  is  loaded 
into  the  queue,  the  old  queued  packet  would  be  chopped  off,  or  malformed.  The  buffer  was  also 
increased,  which  optimized  the  circular  buffer.  In  summary,  this  issue  was  not  one  wherein  the  TOC 
radio  had  incorrectly  received  a  packet.  It  was  one  in  which  the  stored  packet  could  occasionally  be 
overwritten  before  being  sent  to  the  TOC  application  by  the  radio.  This  matter  has  been  corrected  and 
the  issue  of  malformed  packets  has  been  eliminated. 

A  couple  of  issues  stemming  from  the  inconsistencies  related  to  the  invitation  interval  hindered  the 
proper  operation  of  the  system,  and  consumed  excessive  amount  of  time  for  the  formation  of  the 
intended  demonstration-topologies.  A  node  will  attempt  to  register  with  the  first  invitation  it  receives 
with  any  candidate  parent  node.  It  will  transmit  a  response  to  the  candidate  parent  and  will  ignore 
other  invitations  it  receives  thereafter.  The  issue  occurred  when  the  registration  process  failed  and  the 
node  would  remain  in  the  "ignore  invitation"  condition.  Even  though  it  received  invitations  from  a  more 
suitable  candidate  parent,  the  node  remained  in  this  loop.  It  was  discovered  that  if  a  node  deregistered, 
it  would  reset  the  state  or  a  power-cycle  was  necessary  to  clear  the  manifestation.  The  metric  to 
register  with  a  candidate  parent  node  was  a  properly-received  invitation  packet.  The  instructor  node 
and  student  nodes  were  fitted  with  lOdB  fixed  attenuators  for  the  duration  of  Demonstrations  2  and  3. 
This  was  to  provide  better  control  over  the  field-strengths  when  attempting  to  form  the  linear  topology, 
reducing  ranges  to  manageable  levels.  It  was  sometimes  difficult  to  force  the  network  to  assume  a 
desired  topology,  even  when  the  signal  strengths  were  low  and  environmental  features  were  used  as  an 
aid  in  blocking  signals.  Such  tests  of  network-configuration  behavior  are  better  conducted  in  laboratory 
settings,  where  greater  control  can  be  maintained  throughout  the  test. 

Revision  of  the  network-layer  to  eliminate  the  ALOHA  registration-scheme  and  to  introduce  additional 
features  that  significantly  increase  the  efficiency  and  robustness  of  the  features  could  not  be  completed 
in  time  to  allow  sufficient  testing,  prior  to  Demonstration  3.  In  subsequent  testing,  significantly- 
improved  system-stability  and  performance  were  tested  and  verified. 

In  addition  to  the  issues  listed  above,  on  the  second  day  of  the  demonstration-period  (Demonstration 
3),  the  node-configuration  portion  of  the  demonstration  manifested  an  issue  that  was  related  to  how 
the  TOC-node  data  information  was  stored  on  the  Roster.  This  created  a  problem  with  the  extensible 
markup  language  (XML)  parsing  code  on  the  handheld  application.  When  the  instructor  attempted  to 
load  the  Roster  in  to  the  PDA,  via  a  compact  FLASH  (CF)  card,  the  instructor's  handheld  application  did 
not  recognize  the  format.  This  issue  has  since  been  resolved.  The  instructor's  personal  digital  assistant 
(PDA)  also  had  difficulty  accessing  the  Bluetooth  Manager  on  the  PDA's  Program  Files.  For  a  reason  that 
remains  open,  the  Bluetooth  Manager  did  not  appear  under  the  iPAQ  wireless  menu,  and  only  showed 
the  WiFi  connectivity.  This  issue  is  not  present  with  the  use  of  the  Microsoft  Windows  Tablets,  which 
was  integrated  in  place  of  the  PDA's  for  Demonstration  4. 
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During  field  testing,  some  anomalous  behavior  was  observed  when  certain  heart-rate  monitors  failed  to 
connect  and  provide  the  expected  reading.  Heart  rate  work  was  reworked  to  focus  on  the  Zephyr 
BioHarness  3,  as  this  unit  contains  USARIEM  algorithms. 

6.3.2  Demonstration  2  Results 

Table  6  represents  the  analysis  of  the  data  during  the  10-minute  data  collection  for  the  linear  topology. 
Table  7  represents  a  modified  calculation  of  the  recovered  data  packet  transmissions  for  nodes  4  and  5 
after  re-registering  with  a  suitable  parent.  The  9  missing  data  packets  for  GUID  6666,  node  4  and  8  out 
of  9  missing  data  packets  for  GUID  9999,  node  5,  were  recovered  during  this  time. 

The  error  rates  for  GUID  7777,  node  3,  and  GUID  2222,  node  2,  were  due  to  GUID  5555,  node  1.  At  their 
respective  time  slots,  each  node  transmitted  their  data  packets  to  their  corresponding  parents:  GUID 
2222  is  the  parent  of  GUID  7777  and  GUID  5555  is  the  parent  of  GUID  2222  and  grandparent  of  GUID 
7777. 

Reception  by  the  parent  node  (the  instructor)  of  data  packets  from  GUID  5555  (a  child  of  the  parent) 
were  intermittently  declared  as  being  too  degraded  for  proper  reception.  Since  the  instructor  radio  was 
not  able  to  properly  decode  the  packet,  it  was  not  routed  to  the  TOC  and  resulted  in  a  "routed"  packet 
error. 

The  issue  was  subsequently  investigated  in  the  laboratory  and  found  to  be  caused  because  GUID  5555's 
drive-level  to  its  power  amplifiers  was  not  appropriately  adjusted.  Inappropriately-appropriately 
adjusted  drive  levels  of  this  type  cause  distortion  of  the  transmitted  signal  and  negatively  affect 
reception-processing.  The  drive-level  was  properly  readjusted  and  the  reception  issue  was  eliminated. 

Table  6.  Packet  Error  and  Message  Rate  -  Linear  Topology,  Demonstration  2 


NODE 

Parent 

slot 

Anticipated 

Routed 

Packet 

Receptions 

Error 

Count 

Packet 

error  rate 
(PER)  in  % 

Anticipated 
Packet  Receptions 
(Un¬ 
routed/Routed) 

Message 

Throughput 
Rate  in  % 

GUID  1111, 
Instructor 

255 

20 

0 

0 

! 

20 

100 

GUID  5555, 
node  1 

254 

20 

1 

5 

20 

100 

GUID  2222, 
node  2 

1 

20 

3 

15 

20 

100 

GUID  7777, 
node  3 

2 

20 

4 

20 

20 

100 

GUID  6666. 

node  4 

3 

20 

9 

45 

11 

55 

GUID  9999, 
node  5 

4 

20 

9 

45 

12 

60 
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Table  7.  Recovered  Store-and-Forward  Packet  Transmissions  from  Table  6,  Linear  Topology, 
Demonstration  2 


NODE 

Parent  slot 

Anticipated 

Routed 

Packet 

Receptions 

Error  Count 

Packet 

error  rate 
(PER)  in  % 

Anticipated 

Packet 

Receptions  (Un¬ 
routed/Routed) 

Message 
Throughput 
Rate  in  % 

GUID  1111, 
Instructor 

255 

20 

0 

0 

20 

100 

GUID  5555, 
node  1 

254 

20 

1 

5 

20 

100 

GUID  2222, 
node  2 

1 

20 

3 

15 

20 

100 

GUID  7777, 
node  3 

2 

20 

4 

20 

20 

100 

GUID  6666, 
node  4 

3 

20 

4 

4 

20 

100 

GUID  9999, 
node  5 

4 

20 

1 

5 

20 

100 

6.3.2.1  Overall  Packet-Error-Rate  (PER)  and  Message  Throughput  Rate  for  Full  Duration  of 
Demonstration  2 

Table  8  illustrates  the  overall  PER  and  message  throughput  rate  for  the  full  2  hour  duration  of 
Demonstration  2  functionalities.  The  PER  is  an  aggregate  of  the  system  reliability  issues  the  individual 
nodes  experienced,  which  have  been  referenced  in  Section  6.3.1.  The  store-and-forward  function  was 
able  to  restore  a  great  number  of  packets  that  were  otherwise  "lost"  in  the  routed  packet  receptions,  as 
well  as  the  message  throughput  rate.  Table  9  illustrates  the  original  PER  for  the  nodes  and  the 
recovered  number  of  data  packets  once  the  store-and-forward  functionality  was  triggered.  For 
example,  during  the  execution  of  the  store-and-forward  functionality,  10-minute  separation  of  2  nodes, 
GUID  1111,  instructor  radio  experienced  an  exception  where  its  radio  locked-up  and  had  to  recycle 
power.  Its  downtime  was  between  17:58:30  and  18:06:36.  During  this  time,  with  the  exception  of  GUID 
5555,  node  1,  the  instructor's  children  began  broadcasting  their  data  packets  and  storing  and 
incrementing  their  store-and-forward  data  packets.  The  node's  broadcasted  data  was  received  by  the 
TOC  radio  node  and  attributed  to  an  improved  message  throughput  rate.  The  transmission  of  the  store- 
and-forward  data  packets,  once  the  nodes  reregistered  with  the  instructor  and  their  respective  parents, 
improved  since  the  "lost"  packet  was  retransmitted  in  the  node's  store-and-forward  interval. 
Unfortunately,  GUID  5555's  radio  also  locked  on  two  occasions  and  did  not  activate  the  store-and- 
forward  functionality  and  had  no  way  of  recovering  its  data  during  these  times. 

In  different  points  of  the  test,  GUID  1111,  instructor  node  and  GUID  5555,  node  1  experienced  radio 
performance  issues  that  caused  their  individual  radios  to  lock-up,  and  therefore  needed  to  recycle  their 
power  to  clear  the  exception.  When  a  radio's  power  is  recycled,  it  refreshes  its  network  condition.  A 
node  first  has  to  deregister  and  broadcast  its  data  for  the  store-and-forward  to  commence.  For  the  rest 
of  the  nodes,  even  though  the  instructor's  radio  had  powered  off,  and  they  no  longer  had  a  viable 
parent  to  route  their  data  packet  to  the  TOC  node,  they  individually  began  broadcasting  their  data 
packets  and  the  TOC  node  was  able  to  receive  their  un-routed  packets.  Once  the  instructor  was  back  on 
the  network,  the  nodes  began  transmitting  their  current  and  stored  data  packets  in  their  buffer  queue 
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Table  8.  Overall  calculation  of  error  rates  for  full  duration  of  Demonstration  2 


Nodes 

Duration 

(Approximately 

2  hrs) 

Anticipated 

Routed 

Packet 

Receptions 

Error 

Count 

Packet 

error  rate 
(PER)  in  % 

Anticipated 

Packet 

Receptions 

(Un¬ 

routed/Routed) 

Message 
Throughput 
Rate  in  % 

GUID1111, 

Instructor 

17:38:8 

19:36:8 

236 

79 

33.5 

157 

66.5 

GUID5555, 
node  1 

17:38:10 

19:36:10 

236 

19 

37.3 

181 

76.7 

GUID  2222, 
node  2 

17:38:14 

19:36:14 

236 

65 

27.5 

227 

96.2 

GUID  7777, 

node  3 

17:38:18 

19:36:18 

236 

64 

27.1 

226 

95.8 

GUID  6666, 
node  4 

17:38:22 

19:32:54 

229 

65 

25.8 

216 

94.3 

GU ID  9999, 
node  5 

17:38:26 

19:33:26 

230 

63 

27.4 

212 

92.2 

Table  9.  Recovered  Data  Packets 


Nodes 

Duration 
(Approximately 
2  hrs) 

Anticipated 

Routed 

Packet 

Receptions 

Original 

Error 

Count 

Packet 

error 

rate 
(PER) 
in  % 

Recovered 
number  of 
Packets 

Packet 

error 

rate 
(PER) 
in  % 

Improvements 
calculated  in 

% 

GUID 

1111, 

Instructor 

17:38:8 

19:36:8 

236 

79 

33.5 

0 

n/a 

n/a 

GUID 
5555, 
node  1 

17:38:10 

19:36:10 

236 

88 

37.5 

0 

n/a 

n/a 

GUID 
2222, 
node  2 

17:38:14 

19:36:14 

236 

81 

34.3 

16 

27.5 

6.8 

GUID 
7777, 
node  3 

17:38:18 

19:36:18 

236 

88 

37.3 

24 

27.1 

10.2 

GUID 
6666, 
node  4 

17:38:22 

19:32:54 

229 

94 

41 

35 

25.8 

15.2 

GUID 
9999, 
node  5 

17:38:26 

19:33:26 

230 

106 

46.1 

43 

27.4 

18.7 
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Figure  50.  Illustration  of  Linear,  5-Hop  Topology  Demonstration 

6.3.3  Demonstration  3  Results 

In  Table  10,  the  high  error  count  for  GUID  2222,  node  2  is  due  to  radio  operation  locking-up  and  the 
node  had  to  recycle  its  power  at  18:05:59,  to  clear  the  event.  Since  this  was  during  the  data  collection 
period  for  the  linear  topology,  2  minutes  of  its  data  was  not  transmitted  during  this  time  and  accounts 
for  its  high  PER  and  lowered  message  rate  throughput.  These  data  packets  are  not  recoverable  since 
power-cycling  refreshes  its  network  framework.  Node  2  radio  power  cycling  greatly  impacted  the  rest  of 
the  nodes  in  the  topology,  who  were  relying  on  node  2  to  forward  their  individual  data  packets  to  the 
instructor.  Node  2  is  the  direct  and  indirect  parent  of  nodes  3,  4  and  5.  In  the  linear  topology,  the  only 
other  suitable  candidate  parent  node  that  node  3  can  re-register  with  was  node  1.  It  cannot  register 
with  either  nodes  4  and  5  since  they  are  the  child  and  grandchild  of  node  3.  The  distance  between 
nodes  1  and  3  was  approximately  112  meters  and  20dB  of  attenuation  between  the  two  nodes,  which 
was  not  favorable  to  allow  a  registration  to  occur.  The  distance  between  node  3  and  node  1  would  have 
to  be  reduced  in  order  for  registration  to  transpire.  As  it  was,  the  objective  was  for  all  nodes  to  hold 
their  position  until  node  2  re-acquired  a  GPS  fix  and  repossess  its  place  in  the  linear  topology,  in  order  to 
continue  with  the  demonstration,  as  planned.  The  TOC  was  continually  receiving  un-routed  packets 
directly  from  the  nodes  during  this  time,  with  the  exception  of  node  2.  Therefore,  the  message 
throughput  rate  for  nodes  3,  4  and  5  was  not  impacted. 

Other  issues  present  during  this  segment  of  the  demonstration  were  the  link  quality  between  the  nodes 
that  created  additional  errors  to  occur. 
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Table  10.  Packet  Error  and  Message  Rate  -  Linear  Topology,  Demonstration  3 


NODE 

Parent 

slot 

Anticipated 

Routed 

Packet 

Receptions 

Error 

Count 

Packet 

error  rate 
(PER)  in  % 

Anticipated 
Packet  Receptions 
(Un¬ 
routed/Routed) 

Message 
Throughput 
Rate  in  % 

GUID1111, 

Instructor 

255 

20 

2 

10 

18 

90 

GUID5555, 
node  1 

254 

20 

S 

5 

20 

100 

GUID2222, 
node  2 

1 

20 

4 

20 

16 

80 

GUID7777, 
node  3 

2 

20 

6 

35 

20 

100 

GUID6666, 
node  4 

3 

20 

S 

35 

19 

95 

GUID9999, 
node  5 

3 

20 

8 

40 

18 

90 

Figure  51.  Illustration  of  Linear,  5-Hop  Topology  Demonstration 
6.3.3.1  Linear  Topology  and  911  Demonstration 

The  transmission  of  911  messages  from  each  student  node  to  the  instructor  node  and  TOC  node  was 
demonstrated  using  the  linear  topology,  following  the  10-minute  store-and-forward  demonstration. 
Each  student-node  was  instructed  to  press  their  911  alert  button,  the  reception  of  which  was  confirmed 
by  observing  the  TOC  application  and  the  instructor  application.  The  visual  display  of  a  received  911 
transmission,  by  a  student-node,  via  the  TOC  and  instructor  applications  was  verified  by  the  node's  icon 
turning  from  green  (TOC  is  continuously  receiving  data  packets  from  node)  to  red.  An  icon  turning  red 
can  signal  either  a  911  event  has  occurred  and/or,  depending  on  the  configurations  the  TOC  operator 
had  set  on  the  application,  can  also  indicate  that  a  critical  threshold  has  been  exceeded.  The  reception 
of  the  911  message  transmission  was  visually  confirmed  by  the  customers  stationed  at  the  TOC  location, 
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while  another  customer  was  stationed  with  the  instructor,  in  the  field.  The  911  demonstration  was 
performed  starting  with  the  last  node  in  the  topology  link,  node  2,  and  finishing  with  the  instructor. 

The  message  transmission  latency  (transit  time)  measured  by  the  customer  was  between  7  seconds  to 
30  seconds. 

6.33.2  Laboratory  Demonstration  Activity  of  Store-and-Forward  (30-minutes,  2-node,  separation) 

With  respect  to  the  store-and-forward,  the  half-hour-long  separation  was  demonstrated  in  the  lab,  using 
attenuators  to  separate  the  nodes  from  the  rest  of  the  network. 

The  following  laboratory-demonstration  activity  showed  the  operation  of  the  store-and-forward  feature 
of  the  network  for  the  case  of  30-minute  separation  of  two  nodes.  After  expiration  of  the  30-minute 
separation-period,  the  first  node  was  reestablished  as  a  leaf  node.  Next,  the  second  node  rejoined  the 
network  as  a  child  of  the  first  node,  transforming  the  first  node  from  a  leaf  (child)  to  a  branch  (parent) 
node. 

The  test  was  terminated  after  all  stored  packets  have  been  transmitted  by  the  respective  nodes-of- 
origin.  By  previous  agreement,  the  nodes  did  not  maintain  subnets  because  this  does  not  optimally 
facilitate  independent  reconnection  and  the  stored  data  gets  forwarded,  regardless. 

From  the  perspective  of  timely  re-registration  and  data-transfer,  this  design  is  more  efficient  under  the 
unique  operational-requirements  and  constraints  of  the  SPARNET  system.  Accordingly,  subnet 
operation  is  intentionally  not  supported  by  the  SPARNET  network-layer  and  was  not  demonstrated. 
However,  the  independent  separation  and  independent  rejoining  of  nodes  is  consistent  with  the  more 
rapidly-reconfiguring  model  and  was  demonstrated  for  cases  in  which  nodes  that  have  rejoined  the 
network  and  are  forwarding  data  will  operate  as  a  parent-  (branch)  and/or  a  child-node  (leaf). 

Table  11  below  represents  the  recovered  data  packets  for  the  span  of  30  minutes  for  which  the  two 
nodes  were  disconnected  from  the  network.  All  the  routed,  stored  packet  errors  the  two  nodes 
encountered  were  due  to  the  TOC  radio  receiving  the  forwarded  data  packets  from  the  instructor  as 
preamble  errors,  with  a  high  AGC  power  level. 

Performance  of  this  portion  of  the  demonstration  in  the  lab  environment,  with  radio  nodes  being  such  a 
close  distance  from  one  another,  the  TOC  radio  failed  to  receive  the  transmissions  correctly.  This 
problem  is  known  to  the  design-team  and  future  work  and  enhancements  will  be  made  to  address  this 
matter. 

The  percent  of  error  for  node  5  in  the  message  throughput  rate  column  is  due  to  the  TOC  Data  Broker 
determining  the  packets  as  malformed.  The  TOC  node  received  all  of  node  5's  routed  and  un-routed, 
stored  packets,  as  evident  in  the  TOC  CLI,  but  the  Data  Broker  could  not  decipher  the  data-packet 
messages. 
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Table  11.  Packet  Error  and  Message  Rate  for  30-minute,  2-node,  Store-and-Forward 


Off -net 
Nodes 

Recovered 
Separation 
Time 
(30  mins) 

Anticipated 

Routed 

Packet 

Receptions 

Number  of 
Received 
routed, 
stored 
packets 

Packet 

error  rate 
(PER)  in  % 

Anticipated 

Packet 

Receptions 

(Un¬ 

routed/Routed) 

Message 
Throughput 
Rate  in  % 

GUID6666, 
node  4 

23:15:22- 

19:44:52 

60 

52 

13.3 

60 

100 

GUID9999, 
node  5 

23:15:56- 

23:45:26 

60 

52 

3.3 

58 

96.7 

6.3.3. 3  Overall  Packet-Error-Rate  (PER)  and  Message  Throughput  Rate  for  Full  Duration  of 
Demonstration  3 

An  overall  PER  and  message  throughput  rate  was  not  calculated  for  the  full  duration  of  Demonstration 
3.  The  rationalization  behind  this  was  that  the  error  rates  would  be  misleading  based  on  2  conditions: 
a)  student-node  radios  were  powered  off  during  the  bypass  connectivity  demonstration  (Section  5.10  of 
Demonstration  3  technical  report)  and  b)  the  ad-hoc  test  initiated  by  the  customer  at  the  conclusion  of 
the  formal  Demonstration  3  requirements.  As  previously  mentioned,  the  same  code  revision  resided  on 
both  Demonstration  2  and  Demonstration  3.  One  can  infer  that  the  overall  calculation  of  error  rates  for 
Demonstration  2  would  be  the  similar  to  that  of  Demonstration  3. 

6.4  December  Demonstration 

This  previously-unscheduled,  interim  demonstration,  held  on  December  16,  2011,  was  conducted  to 
showcase  the  progress  made  in  resolving  issues  of  system  stability  that  were  observed  in  Demonstration 
2  and  Demonstration  3.  The  enhanced  registration  architecture,  which  eliminated  the  ALOHA  invitation 
scheme,  was  demonstrated,  along  with  an  integrated  Repeater  which  served  as  a  communication 
backbone  between  the  field  and  the  TOC  radio.  The  removal  of  the  ALOHA  scheme  and  the  integration 
of  the  new  managed  network  architecture  resulted  in  a  more  reliable  and  robust  registration  process, 
and  eliminated  inconsistencies  and  issues  associated  with  the  ALOHA  architecture.  Key  objectives  of 
engineering  the  SPARNET  network-layer  to  operate  as  a  "managed  network"  maximized  graceful  control 
of  the  system  and  provided  greater  flexibility  to  tailor  the  system  to  meet  application-specific 
requirements  and  enabled  the  best  use  of  the  limited  spectral  bandwidth  provided  for  the  network. 

A  repeat  of  the  combined  elements  of  Demonstration  2  and  Demonstration  3  were  demonstrated. 
Functionality  intended  for  Demonstration  4,  integration  of  a  repeater-node,  was  exercised.  The  aim  was 
to  have  the  instructor  register  with  the  repeater  as  opposed  to  the  TOC  radio  node.  During  the 
demonstration,  the  instructor  registered  with  the  repeater  node,  which  was  registered  with  the  tactical 
operations  center  (TOC).  This  displayed  a  network  self-configuration  with  the  TOC  as  a  root  and  the 
repeater  node  as  a  child. 

At  the  conclusion  of  the  December  demonstration,  a  range  test  was  conducted  to  exhibit  the 
advancement  of  the  radio  performance.  The  test  consisted  of  the  TOC,  repeater,  instructor  and  5 
student  nodes.  The  distance  was  demonstrated  between  an  instructor  node  and  1  student  node  (Radio 
19,  node  5),  with  the  use  of  the  high-power  power  amplifier.  The  rest  of  the  nodes  were  operating  using 
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the  low-power  power  amplifier.  The  maximum  distance  reached  between  the  two  nodes  exceeded 
1000  meters,  with  0%  message-error-rate.  The  location  of  the  various  nodes  during  testing  is  shown  in 
Figure  52. 


Figure  52.  Illustration  of  Range  Test,  between  Instructor  and  student  node 

There  were  several  issues  present  during  this  demonstration.  The  bypass-connectivity  demonstration 
(student-radio  bypass  per  PWS  3f)  still  had  issues  with  connection  between  the  instructor's  Bluetooth- 
enabled  tablet  and  the  student  node's  POLAR  heart  rate  monitor.  This  issue  was  resolved  by  moving 
forward  with  the  Zephyr  heart  rate  monitor  units  for  Demonstration  4.  A  series  of  clean-up  activities 
were  concluded  based  on  the  outcome  of  the  December  demonstration.  Most  of  which  were  related  to 
the  applications. 

All  in  all,  this  demonstration  illustrated  a  powerful  and  reliable  system  capable  of  bypassing  the 
threshold  range  requirement  and  achieving  the  objective  distance  of  1000  meters,  as  specified  in  the 
project  work  statement  (PWS). 

6.5  Demonstration  4  Results 

Demonstration  4  was  concluded  on  February  02,  2012.  Foundational  work  was  advanced  to  support 
Demonstration  4  functionalities  such  as,  integration  of  the  new  managed  network  scheme,  construction 
of  the  repeater  backbone,  integration  of  the  Zephyr  BioHarness  3  heart  rate  monitor  units  and  bi¬ 
directional  communication  via  911-messaging.  Work  to  advance  aspects  of  the  Option  Year  1  tasks, 
such  as  the  operation  of  multi-squad  and  multi-instructor  network,  as  well  as  the  recovery  of  an  off- 
network  student  was  achieved.  The  capability  to  store,  format,  download  and  the  subsequent  exporting 
of  data  stored  on  an  individual  node  was  executed.  The  capability  for  the  TOC  to  import  and  export 
roster  data  and  equipment  list  was  advanced.  Handheld  Speech's  voice  command  of  the  instructor's 
mapping  application  was  demonstrated. 
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6.5.1  Issues  Observed  in  Demonstration  4 

There  were  two  key  issues  cited  in  the  Demonstration  4  technical  report.  One  occurred  in  the  field 
where  the  repeater  node  would  intermittently  receive  the  instructor  node's  forwarded  data  packets  as 
errors.  The  second  being  the  laboratory  portion  of  the  demonstration  wherein  the  instructor's  radio  did 
not  parse  correctly. 

6.5. 1.1  FLASH  Parser 

During  the  laboratory  execution  of  the  parsing  of  the  downloaded  node  data  for  the  instructor's  radio 
node,  the  downloading  of  the  stored  flash  data  for  the  instructor's  radio  did  not  function  properly.  The 
"dump  8"  command  was  successfully  executed  from  HyperTerminal;  however  the  flash  parser  produced 
a  file  with  no  lines  of  text.  Below  are  the  first  few  lines  of  the  captured  text  from  HyperTerminal. 

[54:39.329]  Batt  is  6.850  Vdc[54:39.334]  State  is  GREEN 

[54:39.340]  sparnetP3> 

[54:40.140]  sparnetP3> 

[54:40.324]  sparnetP3> 

[54:40.478]  sparnetP3>[54:40.552]  BT  No  Carrier  LinkO 
[54:40.557]  HR  was  12  at  00:00:00,  now  0 

[54:40.642]  sparnetP3> 

[54:40.826]  sparnetP3> 

[54:40.955]  sparnetP3>dump  8 

Flash  Log  [14500]=... 

0, 

50, 

The  parser  is  intended  to  read  HyperTerminal's  captured  text  line  by  line  and  begin  to  process  data 
immediately  after  the  string  "Flash  Log  [14500]".  The  text  filter,  or  regular  expression,  was  based  on 
searching,  rather  than  matching,  a  line  of  text  that  contains  an  integer  followed  by  a  comma  (i.e.  '(\d+),' 
in  Python  notation).  Notice  that  the  line  with  time-stamp  [54:40.557]  contains  a  string  with  this 
property,  namely  "00:00:00,". 

At  the  time  of  the  demonstration,  the  parser's  logic  was  correct,  but  slightly  flawed.  Once  a  string  of  the 
time  specified  above  was  encountered,  the  line  was  deemed  to  be  a  byte  from  the  radio’s  FLASH 
memory.  Moreover,  when  a  line  of  this  type  was  no  longer  encountered,  the  line  was  deemed  to  no 
longer  be  from  the  radio's  FLASH  memory,  and  the  parser  was  terminated.  The  line  immediately 
following  the  line  with  time-stamp  [54:40.557]  is  blank  and  therefore  was  considered  to  not  be  part  of 
FLASH  memory.  As  a  result  no  packet  was  processed.  The  problem  has  been  solved  by  using  matching 
rather  than  searching.  Moreover,  the  FLASH  processing  is  terminated  only  after  the  FLASH  dump 
completion  message  is  observed  in  the  log  file.  With  these  changes,  we  have  been  able  to  successfully 
dump  and  parse  the  FLASH  memory  from  the  instructor's  radio. 

6.5. 1.2  Intermittent  Packet  Reception  Issue  between  Instructor  Node  and  Repeater  Node 

All  testing  to  date  has  demonstrated  that  the  issue  where  the  repeater  node  would  intermittently 
receive  the  instructor's  forwarded  data  packet  as  an  error  is  attributed  to  the  spurious  components 
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originating  at  the  affected  instructor-node.  Under  several  testing  conditions,  the  original  instructor 
radio,  used  during  the  execution  of  Demonstration  4,  was  substituted  for  another  instructor  radio  node 
and  the  original  repeater  radio  was  integrated  and  used  for  these  testing  purposes.  Examination  of  the 
collected  data  showed  that  the  probability  of  the  error  occurring  markedly  decreased  with  the 
replacement  of  the  instructor  node.  Further  investigation  and  debugging  of  the  instructor  radio  node 
will  be  necessary  to  isolate  and  determine  the  precise  source  of  the  problem. 

6.5.2  Update  Rate  Calculations  of  30-second  Period  vs.  1-minute  Period 

The  node  count  requirement  for  base  year  one  of  the  project  consisted  of  demonstrating  support  for 
one  TOC,  one  repeater,  one  instructor  and  five  student-nodes.  The  SPARNET  network  layer  was  scaled 
and  configured  to  serve  this  purpose.  The  network  was  designed  to  update  twice-a-minute  (30-second 
period)  for  the  purpose  of  the  demonstrations.  Two  sets  of  metrics  were  calculated  for  the  individually 
executed  requirements  set  forth  under  Demonstration  4:  twice-a-minute  (30-second  period)  and  once- 
a-minute  (60-second  period).  The  reporting  of  packet  error  rate  and  message  throughput  rates  were 
calculated  separately  based  on  these  two  metrics. 

The  set  of  data  contained  in  Table  12,  Table  14  Table  16,  Table  18,  Table  20  and  Table  22  is  for  the  twice- 
a-minute  (30-second  period)  update  rate  and  the  same  data  sets  were  recalculated  based  on  the  once-a- 
minute  update  rate  as  exemplified  in  Table  13,  Table  15,  Table  17,  Table  19,  Table  21  and  Table  23.  Even 
though  the  SPARNET  network  updates  twice-a-minute  (30  second  period),  in  the  recalculation,  the  basis 
was  that  if  any  data  packet  was  successfully  received  by  the  TOC  for  an  end  node,  within  a  span  of  a 
minute,  it  was  deemed  to  be  a  successful  packet  reception.  As  an  example,  if  the  TOC  received  a  bad 
packet  or  no  packet  at  all  for  node  4  at  02:21:00  (hh:mm:ss),  but  received  a  good  packet  for  node  4  at 
02:21:30,  in  the  recalculation,  this  would  only  count  as  1  good  data  packet  reception  for  the  one  minute 
time  frame  of  02:21:00-02:21:30.  This  is  the  foundation  of  the  metric  for  calculating  the  error  rate  and 
message  throughput  rate  for  the  contract-specified  60-second  period  (1-minute).  Each  data  packet 
transmitted  by  a  node  is  unique,  frame-by-frame,  as  Elintrix  did  not  conduct  any  of  the  four  required 
demonstrations  with  the  use  of  any  simulated  data.  Using  this  principle,  the  data  reported  in  Tables  3, 
5, 7,  9, 11, 14  and  16  displays  an  improved  error  rate  and  message  throughput  rate  from  their  respective 
counterparts. 

6.5.3  Star  Topology  (Body-Worn  Antenna)  Demonstration  Results 

The  high  error  rate  for  GUID  6666,  node  7,  as  exemplified  in  Table  12  and  Table  13,  was  attributed  to  the 
instructor  forwarding  node  7's  data  packet  to  the  repeater  node.  The  repeater  node  would  consistently 
receive  the  forwarded  data  packet  from  the  instructor  as  an  error.  Since  the  repeater  node  received  it 
as  an  error,  it  did  not  subsequently  route  the  data  packet  to  its  parent,  the  TOC  node,  which  resulted  in 
a  high  packer  error  rate  for  node  7.  The  error  rates  for  GUID  2222,  node  5  and  GUID  9999,  node  8,  were 
from  the  same  issue. 

In  the  following  demonstration  for  the  star  topology,  where  nodes  mounted  rubber  duck  antennas  on 
their  radio  units,  the  phenomenon  was  more  prominent  across  all  the  nodes,  for  when  the  instructor 
forwarded  its  chil  ren's  data  packets  to  the  repeater  node.  Table  14  and  Table  15  exemplify  the  errors 
encountered  through  the  5-minute  data  collection  of  the  star  topology  with  the  rubber  duck  antennas. 

As  presented  in  Figure  53  (image  on  the  left),  the  distance  of  the  TOC  from  the  repeater  and  the 
instructor  and  its  squad  was  460  meters.  The  TOC  node  and  repeater  node  remained  stationary  during 
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the  whole  duration  of  Demonstration  4.  The  high  power  R.F.  power  amplifier  (PA)  was  enabled  between 
the  TOC  node  and  repeater  node  only,  during  the  full  extent  of  Demonstration  4. 


Figure  53.  Illustrations  of  Star  Topology  (Body-worn  Antenna)  Demonstration 


The  message  throughput  rate  for  the  instructor  and  the  five  trainee  nodes  were  handicapped  by  the 
distance  of  460  meters  between  the  TOC  and  end-nodes.  Taking  into  account  the  distance  between  the 
nodes  and  the  TOC,  primarily  only  routed  messages  emanating  from  the  repeater  node  were  being 
received  by  the  TOC  radio,  during  the  star  topology  exercises  (body-worn  antenna  and  rubber  duck 
antenna). 

Depending  on  the  locations  of  the  end-nodes  and  based  on  the  demonstration  test  activity,  coupled 
with  the  distance  of  the  end-nodes  relative  to  the  TOC  node,  the  TOC  was  able  to  receive  un-routed  data 
packets  directly  from  the  nodes.  But  mostly,  the  message  throughput  rate  and  packet  error  rate  were 
equivalent. 

The  problem  wherein  the  repeater  was  receiving  a  large  number  of  errors  for  data  packets  forwarded  by 
the  instructor  warrants  further  investigation  and  the  execution  of  well  formulated  set  of  tests  in  the 
laboratory  and  in  the  field  to  determine  the  fundamental  of  the  problem. 

As  will  be  discussed  in  detail  in  Section  6.5.5  Linear  Topology  (Rubber-ducky  Antenna)  Demonstration 
Results,  of  this  report,  the  issue  where  the  repeater  node  was  receiving  an  immense  number  of  the 
instructor's  forwarded  data  packets  as  errors  was  not  present.  The  linear  topology  causes  the  greatest 
amount  of  packet-traffic  because  of  the  retransmissions  required  by  the  multi-hop  link  used  to  convey 
information  from  the  originating  node  to  the  Instructor-node,  repeater  node  and  TOC  node.  For  this 
anomaly  not  to  present  itself  during  the  linear  topology  was  unexpected. 

Another  oddity  was  that  this  issue  did  not  seem  to  affect  the  forwarded  data  packets  for  the  instructor 
and  GUID  3333,  node  4.  As  displayed  in  Table  12,  Table  13,  Table  14  and  Table  15,  the  packet  error  rates 
for  the  2  nodes  were  perfect. 


Page  99  of  116 


For  Official  Use  Only  (FOUO) 


Table  12.  Packet  Error  and  Message  Rate  -  Star  Topology,  Body-Worn  Antenna,  30-second  period 


NODE 

Parent 

slot 

Anticipated 

Routed 

Packet 

Receptions 

Error 

Count 

Packet 
error  rate 
(PER)  in  % 

Anticipated 
Packet  Receptions 
(Un¬ 
routed/Routed) 

Message 
Throughput 
Rate  in  % 

QUID  8888, 
Repeater 

1 

10 

0 

0 

10 

100 

GUID  1111, 
Instructor 

2 

10 

0 

0 

10 

100 

GUID  3333, 
node  4 

3 

10 

0 

0 

10 

100 

GUID  2222, 
node  5 

3 

10 

1 

10 

9 

90 

GUID  7777, 
node  6 

3 

10 

0 

0 

10 

100 

GUID  6666, 
node  7 

3 

10 

7 

70 

4 

40 

GUID  9999, 
node  8 

3 

10 

1 

1 

9 

90 

Table  13.  Packet  Error  and  Message  Rate  -  Star  Topology,  Body-Worn  Antenna,  1-minute  period 


NODE 

Parent 

slot 

Anticipated 

Routed 

Packet 

Receptions 

Error 

Count 

Packet 

error  rate 
(PER)  in  % 

Anticipated 
Packet  Receptions 
(Un¬ 
routed/Routed) 

Message 
Throughput 
Rate  in  % 

GUID  8888, 
Repeater 

1 

5 

0 

0 

5 

100 

GUID  1111, 
Instructor 

2 

5 

0 

0 

5 

100 

GUID  3333, 
node  4 

3 

5 

0 

0 

5 

100 

GUID  2222, 
node  5 

3 

5 

0 

0 

5 

100 

GUID  7777, 
node  6 

3 

5 

0 

0 

5 

100 

GUID  6666, 
node  7 

3 

5 

2 

40 

4 

80 

GUID  9999, 
node  8 

3 

5 

0 

0 

5 

100 
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Figure  53  and  Figure  54  depict  the  full  range  views  of  the  star  topology  demonstrations.  The  image  on 
the  left  represents  the  positions  and  distance  between  the  TOC  node  and  repeater  node.  The  image  on 
the  right  represents  an  expanded  view  of  the  star  topology  and  the  distance  of  the  instructor  relative  to 
its  parent,  the  repeater  node,  and  between  the  instructor  and  the  5  trainee  nodes. 

6.5.4  Star  Topology  (Rubber-ducky  Antenna)  Demonstration  Results 

As  discussed  thoroughly  in  the  previous  section  (Section  6.5.2),  all  the  errors  experienced  during  this 
portion  of  the  demonstration,  which  are  listed  in  Table  14  and  Table  15,  are  all  contributed  to  the 
instructor  forwarding  its  children's  data  packets,  at  their  respective  time  slots,  to  the  repeater  node  and 
the  repeater  node  receiving  the  forwarded  packets  as  errors. 

Due  in  part  to  a  closer  distance  of  the  trainee  nodes  to  the  TOC  node,  the  TOC  was  able  to  receive  un¬ 
routed  packets  either  directly  from  the  trainee  nodes  or  the  instructor's  forward  of  the  trainee  node's 
packets  to  the  repeater.  It  recouped  the  message  throughput  rate  levels  of  the  afflicted  nodes  to 
improved  levels  than  that  of  the  PER. 

Table  14.  Packet  Error  and  Message  Rate  -  Star  Topology,  Rubber-ducky  Antenna,  30-second  period 


NODE 

Parent 

slot 

Anticipated 

Routed 

Packet 

Receptions 

Error 

Count 

Packet 

error  rate 
(PER)  in  % 

Anticipated 
Packet  Receptions 
(Un¬ 
routed/Routed) 

Message 
Throughput 
Rate  in  % 

GU ID  8888, 
Repeater 

1 

10 

0 

0 

10 

100 

GUID1111, 

Instructor 

2 

10 

0 

0 

10 

100 

GUID3333, 
node  4 

3 

10 

0 

0 

10 

100 

GUID2222, 
node  5 

3 

10 

6 

60 

6 

60 

GU  ID  7777, 
node  6 

3 

10 

5 

50 

7 

70 

G Ul D  6666, 
node  7 

3 

10 

5 

50 

8 

80 

GUID9999, 
node  8 

3 

10 

5 

50 

8 

80 

Table  15.  Packet  Error  and  Message  Rate  - : 

Star  Topology,  Rubber-ducky  Antenna,  1-minute  period 

NODE 

Parent 

Anticipated 

Error 

Packet 

Anticipated 

Message 

slot 

Routed 

Packet 

Receptions 

Count 

error  rate 
(PER)  in  % 

Packet  Receptions 
(Un¬ 
routed/Routed) 

Throughput 
Rate  in  % 

GU  ID  8888, 
Repeater 

1 

5 

0 

0 

5 

100 
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GUID  1111, 
Instructor 

2 

5 

0 

0 

5 

100 

GUID  3333, 
node  4 

3 

5 

0 

0 

5 

100 

GUID  2222, 
node  5 

3 

5 

2 

40 

4 

80 

GUID  7777, 
node  6 

3 

5 

1 

20 

4 

80 

GUID  6666, 
node  7 

3 

5 

1 

20 

5 

100 

GUID  9999, 
node  8 

3 

5 

i 

20 

4 

80 

Figure  54.  Illustrations  of  Star  Topology  (Rubber-duck  Antenna)  Demonstration 


6.5.5  Supplementary  Range  Demonstration 

Following  the  star  topology  rubber  duck  antenna  demonstration,  a  range  test  was  conducted  to  show 
the  advancement  of  the  radio  performance.  One  member  of  the  squad,  GUID  9999,  node  8,  walked  to 
extend  its  range  to  the  instructor  with  the  intention  of  demonstrating  that  single-link  communication 
exceeds  the  500-meter  target  set  in  the  PWS.  The  instructor  and  node  8  activated  their  high  power  R.F. 
PA  for  this  exercise.  The  remaining  four  nodes  in  the  squad  continued  to  operate  with  the  low  power 
R.F.  PA.  Node  8  proceeded  to  the  east  range  test  position  on  the  southern  hillside,  east  of  Regents 
Road,  while  the  instructor,  accompanied  by  the  remaining  members  of  the  squad  walked  briskly  to  the 
east  facing  wall  of  the  west  side  bathroom  (near  the  TOC  location).  Ultimately,  the  separation  range 
between  the  instructor  and  the  most-distant  trainee  was  930  meters.  Once  the  distance  was  reached, 
the  instructor  and  the  rest  of  the  squad,  including  node  8  stood  in  position  for  5  minutes  for  data 
collection  to  determine  PER  and  message  throughput  rate.  It  is  important  to  note  that,  in  previous 
testing  distances  in  excess  of  1000  meters  were  demonstrated.  It  is  also  important  to  note  that  in  both 
cases  (930-meters  and  1000+  meters)  the  links  were  not  line-of-site  and  included  transmission  through 
forested  area.  Under  actual  line-of-sight  conditions,  greater  ranges  can  be  anticipated,  meeting  or 
exceeding  the  PWS  objective  range  of  1000  meters. 
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Table  16  and  Table  17  represent  the  PER  and  message  throughput  rate  from  the  moment  the  instructor 
and  node  8  activated  their  high  power  R.F.  PA's.  It  illustrates  the  overall  error  rates  for  the  individual 
nodes  as  they  migrated  to  their  intended  destination  to  achieve  a  range  930  meters.  Some  of  the  errors 
accounted  for  in  Table  16  and  Table  17  were  from  the  issue  of  the  repeater  receiving  the  instructor's 
forward  of  its  children's  data  packets  as  errors.  In  the  case  of  node  6  and  node  7,  the  distance  between 
node  7  and  its  parent,  the  instructor,  was  at  236  meters,  as  illustrated  in  Figure  55.  During  this  time, 
node  6  had  registered  with  node  5  and  finally  with  node  7.  The  distance  of  node  6  from  the  instructor 
was  at  285  meters.  This  may  account  for  the  errors  experienced  for  nodes  6  and  node  7,  as  their 
distance  to  the  instructor  was  too  considerable  and  the  instructor  was  not  able  to  properly  receive  their 
individual  or  forwarded  packets.  The  instructor  also  registered  with  the  TOC  node  during  this  time. 

Table  16.  Packet  Error  and  Message  Rate  -  Range  Demonstration,  30-second  period 

NODE 

Parent  slot 

Anticipated 

Routed 

Packet 

Receptions 

Error  Count 

Packet 

error  rate 
(PER)  in  % 

Anticipated 

Packet 

Receptions  (Un¬ 
routed/Routed) 

Message 
Throughput 
Rate  in  % 

GU ID  8888, 
Repeater 

1 

24 

0 

£ 

24 

100 

GUID  1111, 
Instructor 

2/1 

24 

0 

§ 

24 

100 

GUID3333, 
node  4 

3 

24 

1 

4.2 

23 

95.8 

GUID2222, 
node  5 

3 

24 

3 

12.5 

23 

95.8 

GUID7777, 
node  6 

3/5/7 

24 

4 

16.6 

24 

100 

GUID  6666, 
node  7 

3 

24 

3 

12.5 

23 

95.8 

GUID  9999, 
node  8 

3 

24 

1 

4.2 

24 

100 

Table  17.  Packet  Error  and  Message  Rate  -  Range  Demonstration,  1-minute  period 

NODE 

Parent  slot 

Anticipated 

Routed 

Packet 

Receptions 

Error  Count 

Packet 

error  rate 
(PER)  in  % 

Anticipated 

Packet 

Receptions  (Un¬ 
routed/Routed) 

Message 
Throughput 
Rate  in  % 

‘  GUID  8888, 
Repeater 

• 

12 

0 

0 

12 

100 

GUID  1111, 
Instructor 

2/1 

12 

0 

0 

12 

100 

GUID  3333, 
node  4 

3 

12 

0 

0 

12 

100 
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GUID  2222, 
node  5 

3 

12 

1 

8.3 

12 

100 

GUID  7777, 
node  6 

3/5/7 

12 

i 

8.3 

12 

100 

GUID  6666, 
node  7 

3 

12 

0 

0 

12 

100 

GUID  9999, 
node  8 

3 

12 

0 

0 

12 

100 

Figure  55.  Illustration  of  Range  Demonstration,  706  Meters 

Table  18,  Table  19  and  Figure  56  represent  the  final  destination  of  the  instructor,  its  accompanying  four 
trainee  nodes  and  node  8.  The  maximum  distance  reached  was  at  930  meters  as  depicted  on  Figure  56. 
The  tables  illustrate  the  5-minute  data  collection  period  to  conclude  the  PER  and  message  throughput 
rate  for  this  distance.  The  high  error  rate  for  GUID  6666,  node  7  was  due  to  its  link  with  the  instructor, 
as  was  discussed  in  the  previous  paragraph.  When  node  7  would  transmit  its  data  packet  to  its  parent, 
the  instructor,  the  instructor  intermittently  did  not  receive  it.  The  distance  between  the  instructor  and 
node  7  was  approximately  210  meters.  At  the  conclusion  of  the  5-minute  data  collection,  the  instructor 
and  node  8  returned  to  low-power  R.F.  PA  operation.  The  instructor  and  its  accompanying  trainee 
nodes  made  their  way  towards  the  repeater  in  order  to  perform  the  next  demonstration,  linear 
topology. 
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Table  18.  Packet  Error  and  Message  Rate  -  Range  Demonstration,  5-minute  Data  Collection,  30-second 
period 


NODE 

Parent 

slot 

Anticipated 

Routed 

Packet 

Receptions 

Error 

Count 

Packet 

error  rate 
(PER)  in  % 

Anticipated 
Packet  Receptions 
(Un¬ 
routed/Routed) 

Message 
Throughput 
Rate  in  % 

GUID8888. 

Repeater 

1 

10 

0 

0 

10 

100 

GUID  1111, 
Instructor 

1 

10 

0 

0 

10 

100 

GUID3333, 
node  4 

3 

10 

0 

0 

10 

100 

GUID2222, 
node  5 

3 

10 

0 

0 

10 

100 

GUID  7777, 
node  6 

3 

10 

1 

10 

10 

100 

GUID  6666, 
node  7 

7 

10 

6 

60 

10 

100 

GUID  9999, 
node  8 

3 

10 

1 

10 

10 

100 

Table  19.  Packet  Error  and  Message  Rate  -  Range  Demonstration,  5-min.  Data  Collection,  1-minute 
period 


NODE 

Parent 

slot 

Anticipated 

Routed 

Packet 

Receptions 

Error 

Count 

Packet 

error  rate 
(PER)  in  % 

Anticipated 
Packet  Receptions 
(Un¬ 
routed/Routed) 

Message 
Throughput 
Rate  in  % 

GUID  8888, 
Repeater 

1 

5 

0 

0 

5 

100 

GUID  1111, 
Instructor 

1 

5 

0 

0 

5 

100 

GUID  3333, 
node  4 

3 

5 

0 

0 

5 

100 

GUID  2222, 
node  5 

3 

5 

0 

0 

5 

100 

GUID  7777, 
node  6 

3 

5 

0 

0 

5 

100 

GUID  6666, 
node  7 

7 

5 

1 

20 

5 

100 

GUID  9999, 
node  8 

3 

5 

0 

0 

5 

100 
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Figure  56.  Illustration  of  Range  Demonstration,  930  Meters 
6.5.6  Linear  Topology  (Rubber-ducky  Antenna)  Demonstration  Results 

In  this  demonstration,  the  Instructor  node  and  five  trainee  nodes  took  positions  as  necessary  to  form  a 
linear  topology  that  was  linked,  via  the  Instructor  node,  to  the  Repeater  node  and  to  the  TOC  node. 
Rubber-ducky  antenna  units  were  mounted  on  the  Instructor  node  and  trainee  nodes.  The  instructor 
node  and  student  nodes  were  fitted  with  lOdB  fixed  attenuators  for  the  duration  of  the  linear  topology 
demonstration.  This  was  to  provide  better  control  over  the  field-strengths  when  attempting  to  form  the 
linear  topology,  reducing  ranges  to  manageable  levels. 

The  errors  for  GUID  7777,  node  6  and  GUID  6666,  node  7,  were  due  to  the  link  quality  between  node  6 
and  its  parent,  GUID  2222,  node  5.  The  distance  between  node  5  and  node  6  was  approximately  59 
meters.  Reception  by  the  parent  node  (node  5)  of  data  packets  from  GUID  7777,  node  6  (a  child  of  the 
parent)  and  data  packet  from  GUID  6666,  node  7  (grandchild  of  the  parent)  were  intermittently  declared 
as  being  too  degraded  for  proper  reception.  Since  node  5  was  not  able  to  properly  decode  the  packet,  it 
was  not  propagated  through  the  linear  topology  to  be  routed  to  the  TOC  and  resulted  in  a  "routed" 
packet  error. 

Once  the  linear  topology  was  formed,  an  attempt  was  made  to  move  the  distance  gap  closer  between 
all  the  trainee  nodes  to  eliminate  any  poor  link-quality  between  the  nodes.  The  pursuit  was  discarded 
as  nodes  began  moving  closer  to  their  already  established  parent,  some  nodes  hopped  registration  and 
the  network  was  no  longer  in  the  linear  topology.  This  is  simply  the  mechanics  of  forcing  a  linear 
topology  to  occur  in  the  field.  Additional  field  testing  and  stringent  practices  of  the  formation  of  the 
linear  topology  can  correct  the  link  problem  experienced  between  some  of  the  nodes. 
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The  phenomenon  where  the  repeater  would  receive  the  forwarded  data  packets  of  the  instructor's 
children  at  a  high  error  rate  was  not  present  during  the  linear  topology  demonstration. 

Table  20.  Packet  Error  and  Message  Rate  -  Linear  Topology,  30-second  period 


NODE 

Parent 

slot 

Anticipated 

Routed 

Packet 

Receptions 

Error 

Count 

Packet 

error  rate 
(PER)  in  % 

Anticipated 
Packet  Receptions 
(Un¬ 
routed/Routed) 

Message 
Throughput 
Rate  in  % 

GUID8888, 

Repeater 

1 

10 

0 

0 

10 

100 

GUID1111, 

Instructor 

2 

10 

0 

0 

10 

100 

GUID  3333, 
node  4 

3 

10 

0 

0 

10 

100 

GUID  2222, 
node  5 

3 

10 

0 

0 

10 

100 

GUID  7777, 
node  6 

5 

10 

3 

30 

7 

70 

GUID  6666, 
node  7 

6 

10 

3 

30 

7 

70 

GUID  9999, 
node  8 

7 

10 

1 

10 

9 

90 

Table  21.  Packet  Error  and  Message  Rate  -  Linear  Topology,  1-minute  period 


NODE 

Parent 

slot 

Anticipated 

Routed 

Packet 

Receptions 

Error 

Count 

Packet 

error  rate 
(PER)  in  % 

Anticipated 
Packet  Receptions 
(Un¬ 
routed/Routed) 

Message 
Throughput 
Rate  in  % 

GUID  8888, 
Repeater 

1 

5 

0 

0 

5 

100 

GUID  1111, 
Instructor 

2 

5 

0 

0 

1 

5 

100 

GUID  3333, 
node  4 

3 

5 

0 

0 

5 

100 

GUID  2222, 
node  5 

4 

5 

0 

0 

5 

100 

GUID  7777, 
node  6 

5 

5 

0 

0 

5 

100 

GUID  6666, 
node  7 

6 

5 

1 

20 

4 

80 

GUID  9999, 
node  8 

7 

5 

0 

0 

5 

100 
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Figure  57.  Illustration  of  Linear,  5-Hop  Topology  Demonstration 


6.5.7  Bi-directional  Messaging  Separation-case  and  New  Features  Advancement 

In  the  following  test,  it  was  demonstrated  that  the  current  embodiment  of  the  SPARNET  system  has  the 
capability  of  supporting  two  squads,  operating  from  a  single  TOC  and  auto-configured  using  a  single,  R.F. 
frequency.  Because  of  limitations  on  the  number  of  radios,  each  squad  consisted  of  one  instructor  and 
two  students. 

At  the  onset  of  the  test,  a  member  of  the  customer's  group  and  the  test  director  accompanied  node  6 
through  the  complete  process  of  the  exercise.  GUID  9999,  node  8  remained  powered-off  during  this 
part  of  the  demonstration.  GUID  5555,  the  second  instructor,  to  be  used  for  Squad  #2,  was  enabled  and 
appropriate  actions  were  taken  in  order  to  configure  GUID  5555  in  the  network  layer  and  assume  the 
slot  assignment  of  GUID  9999.  In  short,  GUID  5555  was  now  in  slot  8,  the  slot  vacated  by  GUID  9999. 
The  TOC  operator  constructed  the  applicable  modifications  to  the  control  message  in  order  to 
deactivate  GUID  9999  and  to  allow  GUID  5555  in  the  exercise  and  assembled  the  appropriate  trainee 
nodes  in  their  rightful  squads.  Below  was  how  the  2  squads  were  constructed  for  the  exercise. 

Squad  #1 

GUID  1111,  node  3  -  instructor 
GUID  3333,  node  4  -  trainee  node 
GUID  2222,  NODE  5  -  trainee  node 

Squad  tt2 
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GUID  5555,  node  8  -  instructor 
QUID  6666,  node  7 -trainee  node 
GUID  7777,  node  6  -  trainee  node 


During  the  execution  of  this  demonstration,  one  squad  was  positioned  in  the  woods,  west  of  the 
bathroom  that  was  close  to  the  TOC  (Squad  #1,  network  id  1).  The  second  squad  (Squad  #2,  network  id 
2)  remained  on  the  west  side  of  Regents  Road,  nearby  the  repeater.  A  designated  trainee-node,  GUID 
7777,  node  6,  from  the  Regents  Road  squad  (Squad  #2)  was  directed  to  initiate  a  911-alert,  which 
occurred  at  21:00:00,  and  began  walking  away  from  its  squad  toward  Squad  #1.  The  TOC  was  directed 
not  to  acknowledge  the  trainee's  911-alert.  Once  node  6  walked  sufficiently  far  from  Squad  #2,  it  auto- 
disconnected  from  the  network  and  initiated  "broadcast  mode"  (see  Figure  59),  making  its  energy 
detectable  by  any  radio-units  that  are  within  range.  Node  6  deregistered  from  the  network  and  began 
storing  its  data  packets  at  21:02:48.  Once  in  broadcast  mode  (separated  from  its  squad)  the  TOC  was 
commanded  by  the  test  director  to  transmit  an  acknowledgement  to  the  alerting-radio  of  the  911  alert. 


Figure  58.  Illustration  of  2  instructor-led  training  squads 
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Figure  59.  Illustration  of  node  6's  migration  towards  squad  #1,  and  subsequent  off -network  event 

If  the  radio  is  within  range  of  the  TOC,  its  assigned  squad  or  a  repeater,  the  acknowledgement  will  be 
received  and  will  be  displayed  as  "911=ACK"  on  the  LCD  of  its  radio.  This  does  not  mean  that  it  has  been 
connected  back  onto  the  network,  only  that  the  network  has  identified  its  position  and  is  acknowledging 
its  911-alert. 

Figure  58  exemplifies  the  placements  of  the  two  instructor-led  training  squads.  Squad  #1  instructor 
(green  colored  icon,  children  in  light  blue  colored  icons)  was  registered  with  the  TOC  and  squad  #2 
instructor  (blue  colored  icon,  children  in  yellow  colored  icons)  was  registered  with  the  repeater. 

Figure  59  depicts  node  6's  journey  towards  the  TOC  and  Squad  #1  and  the  stations  of  the  two  instructor- 
led  squads.  At  166  meters  distance  from  its  starting  position,  node  6  was  still  connected  to  the  network 
through  its  parent  (at  the  time  of  this  snapshot),  node  7.  The  red  colored  icon  represents  node  6  as  off- 
network  and  broadcasting  its  data  packet,  with  a  distance  of  329  meters  from  Squad  #2  and  144  meters 
from  the  TOC  node. 

In  the  case  that  was  demonstrated,  the  alerting  node  was  within  range  of  the  TOC  and  received  a 
"911=ACK"  message  from  the  TOC  node,  as  symbolized  in  Figure  59.  Node  6  received  the  ACK  from  the 
TOC  on  21:19:38.  Subsequently,  the  TOC,  knowing  the  location  of  the  trainee  node,  configured  the 
control  message  to  include  the  off-net  trainee  in  Squad  #1.  This  message  was  transmitted  to  and 
received  by  the  Squad  #1  instructor.  The  Squad  #1  instructor  caused  the  message  to  be  propagated 
through  its  squad  members.  The  off-net  trainee  recognized  its  radio  ID  number  and  that  it  was  re¬ 
assigned  to  Squad  #1.  It  proceeded  to  rejoin  the  network  by  registering  with  the  instructor  of  the  Squad 
#1  network-topology  (see  Figure  60),  reestablishing  full  ability  to  communicate/direct  it  and  to  monitor 
any  physiological  or  geo-location  information  of  interest.  Node  6  registered  with  the  instructor  at 
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21:21:18  and  began  transmitting  its  current  and  store-and-forward  packets.  Upon  registration,  node  6 
depressed  its  push  button  to  deactivate  its  911  alert.  Once  confirmed  by  the  Squad  #1  instructor  and 
TOC  node,  per  their  respective  mapping  applications,  the  TOC  node  commenced  to  transmit  the 
message  to  node  6  that  rendered  a  "911=OFF"  message  to  be  displayed  on  its  radio  LCD.  This  occurred 
on  21:21:50. 

Node  6  was  instructed  to  stand  in  place  for  a  couple  of  minutes  to  ensure  that  it  was  reliably 
transmitting  its  current  and  store-and-forward  data  packets  to  its  parent,  the  instructor  and  from  the 
instructor  to  the  TOC.  A  decision  was  made  by  the  customer  to  terminate  the  test  and  to  not  consume 
additional  time  in  allowing  node  6  to  fully  expel  all  of  its  store-and-forward  data  packets  remaining  in  its 
buffer  since  the  store-and-forward  functionality  had  already  been  demonstrated  during  the  early  stage 
of  Demonstration  4  and  validated  in  previous  demonstrations. 

In  total,  this  demonstration  exercised  bi-directional  communication  between  the  off-net  trainee  and 
TOC  node,  illustrated  that  an  off-node  radio  will  receive  a  message  that  is  sent  to  it  when  it  is  within 
range  of  appropriate  network  resources  and  can  be  commanded  to  rejoin  a  new  network.  Further,  it  is 
the  case  that  Squad  #1  could  have  been  used  to  discover  the  location  of  the  off-net  soldier,  had  not  the 
TOC  resources  been  more  immediately  available.  That  is,  individual  squads  can  be  used  as  extensions  of 
the  network  to  search  for,  and  recover,  off-net  personnel,  as  required. 


Figure  60.  Illustration  of  node  6's  registration  with  squad  #1  instructor 
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6.5.8  Overall  Packet-Error-Rate  (PER)  and  Message  Throughput  Rate  for  Full  Duration  of 
Demonstration  4 

Table  22  and  Table  23  illustrate  the  overall  PER  and  message  throughput  rate  for  the  3  hour  duration  of 
Demonstration  4  functionalities.  The  PER  is  an  aggregate  of  issues  the  individual  nodes  experienced, 
which  have  been  noted  in  this  report. 

GUID  9999's  number  of  anticipated  routed  packet  receptions  is  lower  than  its  counterparts  since  it  was 
powered  off  during  the  bi-directional  separation-case  demonstration  as  discussed  in  Section  6.5.6.  In  its 
place,  GUID  5555  was  enabled  to  be  utilized  as  a  second  instructor  for  Squad  #2.  The  period  of  9 
minutes  after  the  execution  of  the  range  test,  as  discussed  in  Section  6.5.4,  was  not  considered  in  the 
calculation  for  Table  22  and  Table  23.  Both  the  instructor  and  GUID  9999,  node  8  deactivated  their  high 
power  R.F.  power  amplifier  and  enabled  their  low  power  R.F.  power  amplifier  at  the  completion  of  the 
data  collection.  With  the  distances  achieved  during  the  range  test,  the  nodes  reverting  back  to  the  use 
of  their  low  power  R.F.  power  amplifier  caused  the  TOC  to  not  properly  receive  the  nodes'  transmitted 
data  packets.  9  minutes  was  the  time  it  took  for  the  instructor  and  its  accompanying  squad  to  return  to 
the  eastern  side  of  the  park,  near  the  repeater,  in  order  to  demonstrate  the  linear  topology. 

The  21  minutes  of  time  invested  in  demonstrating  the  bi-directional  messaging  separation  case,  as 
summarized  in  Section  6.5.6  of  this  report,  was  not  calculated  for  GUID  7777,  node  6.  The  notion  was 
that  node  6,  while  off-network,  broadcasting  its  data  and  ultimately  storing  its  off-network  data  packets 
in  its  store-and-forward  buffer,  was  not  allotted  time  to  fully  transmit  the  store-and-forward  data 
packets  in  its  queue  once  it  rejoined  the  network  and  registered  with  the  instructor  of  Squad  #1.  It 
would  be  unjust  to  calculate  this  data  for  node  6  considering  that  it  was  not  able  to  dispatch  all  of  the 
packets  in  its  store-and-forward  queue  that  would  have  recouped  the  full  span  of  its  missing  data  for  the 
time  it  was  off-network.  Otherwise,  the  41  data  packets  missing  for  node  6  would  count  as  errors. 

Table  22.  Overall  calculation  of  error  rates  for  full  duration  of  Demonstration  4,  30-second  period 


Nodes 

Duration 

(Approximately 

3  hrs) 

Anticipated 

Routed 

Packet 

Receptions 

Error 

Count 

Packet 

error  rate 
(PER)  in  % 

Anticipated 

Packet 

Receptions 

(Un¬ 

routed/Routed) 

Message 
Throughput 
Rate  in  % 

GUID  8888; 
Repeater 

18:32:34 

21:23:04 

259 

0 

0 

259 

100 

GUID  1111, 
Instructor 
(1) 

18:32:38 

21:23:08 

259 

1 

0.4 

258 

99.6 

GUID  5555, 
Instructor 
(2) 

20:20:56 

21:22:56 

54 

10 

18.5 

44 

81.5 

GUID  3333, 
node  4 

18:32:40 

21:23:10 

259 

6 

2.3 

254 

98 

GUID  2222, 
node  5 

18:32:44 

21:23:14 

259 

19 

7.3 

245 

94.6 

GUID  7777. 

node  6 

18:32:48 

21:02:18 

217 

24 

11 

201 

92.7 
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GUID6666, 
node  7 

18:32:52 

21:22:52 

258 

26 

10 

233 

90.3 

GUID9999, 
node  8 

18:32:56 

20:29:26 

205 

28 

13.7 

185 

90.2 

Table  23.  Overall  calculation  of  error  rates  for  full  duration  of  demonstration,  1-minute  period 


Nodes 

Duration 

(Approximately 

3  hrs) 

Anticipated 

Routed 

Packet 

Receptions 

Error 

Count 

Packet 

error  rate 
(PER)  in  % 

Anticipated 

Packet 

Receptions 

(Un¬ 

routed/Routed) 

Message 
Throughput 
Rate  in  % 

GUID8888, 

Repeater 

18:32:34 

21:23:04 

132 

0 

0 

132 

100 

GUID  1111, 
Instructor 

(i) 

18:32:38 

21:23:08 

132 

0 

0 

132 

100 

GUID5555, 

Instructor 

(2) 

20:20:56 

21:22:56 

27 

3 

11.1 

24 

88.9 

GUID3333, 
node  4 

18:32:40 

21:23:10 

132 

1 

0.8 

131 

99.2 

GUID  2222, 

node  5 

18:32:44 

21:23:14 

132 

• 

3.8 

130 

98.5 

GUID  7777, 
node  6 

18:32:48 

21:02:18 

in 

4 

3.6 

110 

99.1 

GUID  6666, 
node  7 

18:32:52 

21:22:52 

130 

7 

5.4 

126 

96.9 

GUID  9999, 
node  8 

18:32:56 

20:29:26 

104 

5 

4.8 

99 

95.2 

7  KEY  RESEARCH  ACCOMPLISHMENTS 

Key  accomplishments  for  the  reported  period  include: 

•  Advancement  of  the  purpose-built  SPARNET  SAN  radio  to  satisfactory  maturity  levels. 

•  Increased  range  to  achieve  the  target  of  500  meters  and  illustrated  a  powerful  and  reliable 
system  capable  of  bypassing  the  threshold  range  requirement  and  achieving  the  objective 
distance  of  1000  meters  (1km),  as  specified  in  the  project  work  statement  (PWS). 

•  Implementation  of  Bluetooth-enabled  option-card  and  associated  software  development. 

•  Integrated  physiologic  status  monitoring  via  the  Bluetooth-link,  an  Option  Year  1  task  that  was 
engineered  to  be  demonstrated  in  the  exhibition  of  Demonstrations  2-4. 
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•  Reporting  of  heart  rate  data  on  the  network  layer,  TOC  application  and  instructor  mobile  device. 

•  Optimization  of  the  network  layer  to  enable  functionalities  for  the  advancement  of  Option  Year 
1  functionalities:  the  formation  of  multi-squad  and  multi-instructor  network  by  the  operation  of 
two  Squads  and  recovery  of  an  off-net  student. 

•  Stabilization  of  the  software  defined  radio  algorithms. 

•  Modification  of  hybrid  AGC  architecture  to  operate  on  shorter  sample-intervals.  The  addition  of 
this  AGC  improved  the  number  of  errors  experienced. 

•  Improved  robustness/accuracy  of  calculation  of  signal-amplitude  metrics  used  in  AGC-control 
and  as  a  metric  for  network  formation. 

•  Significant  advancements  in  the  ability  to  capture  and  analyze  signals  and  messages  to  facilitate 
acceleration  of  enhancement  and  debugging  efforts 

Concepts  for  capture/storage  of  live  packets,  based  on  error-messaging  were  developed 

•  Design  and  integration  of  a  new  managed  network  architecture  in  which  the  radios  authorized 
to  be  within  a  squad  can  be  pre-assigned  a  time-slot  by  the  TOC. 

•  Bi-directional  communication  established  between  the  TOC=>trainee  node  and  between 
TOC=>instructor  node. 

•  Integration  of  a  repeater  backbone  layer  to  extend  the  range  of  the  test  venue. 

•  Integration  of  Handheld  Speech's  voice-  and  gesture-driven  software  application  and  handheld 
speech  application  on  the  instructor's  map  application. 

•  Incremental  Improvements  on  the  overall  SPARNET  system  as  validated  on  the  scheduled  four 
demonstrations. 

•  Storage,  formatting  and  downloading  of  data  stored  on  individual  nodes  via  FLASH  memory. 

•  Performance  assessment  software  to  facilitate  the  capture  and  storage  of  performance  metrics 
were  finished  and  tested. 

•  Bi-directional  communication  enabled  between  the  TOC  application/database  and  TOC  radio 
node.  This  feature  allows  the  TOC  personnel  to  manage  the  training  exercise  and  the  squads 
and  gateways  contained  therein. 

•  Ability  for  the  TOC  to  configure  the  instructor's  handheld  unit  with  roster  data  information 
required  for  operation  of  the  instructor's  map  application.  The  roster  information  contains  the 
list  of  trainees,  along  with  a  time-slot  assignment  from  a  master  list  of  available  time-slot 
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•  Integrated  capability  for  the  instructor's  mapping  application  to  send  the  roster  data 
information  it  received  from  the  TOC  to  the  instructor's  radio. 

•  Mapping  Control,  central  to  the  TOC  and  Instructor  handheld  software  applications,  was 
advanced  to  provide  a  variety  of  new  status  indicators  for  each  participant  such  as  heart  rate 
data,  slot  assignment,  parent's  slot  assignment  and  topology  shifts.  Other  enhancements 
include  the  calculation  of  distance  and  bearing  from  a  student  and  its  instructor  and  a  ruler 
function  to  determine  the  distance  between  any  two  points  on  the  map. 

•  Successfully  integrated  graphical  user  interface  (GUI)  into  the  TOC  and  Instructor  handheld 
software  applications  that  includes  such  features  as  enhanced  management  and  configuration 
capabilities,  visualization  and  analysis  of  received  data,  graphing/charting  capability,  display  of 
time-series  graphs  of  packet-error-rate,  ability  to  recall  old  test  data  and  meta-data,  reporting 
and  plotting  of  sensor  data,  improved  alerting  functionalities,  and  integration  of  Handheld 
Speech,  a  voice  command  application. 


8  CONCLUSION 

The  Base  Year  objectives  and  requirements  set  forth  in  the  Performance  Work  Statement  (PWS)  for  U.S. 
Army  contract  number  W911QY-11-C-0012,  "Integrated  Short  Range,  Low  Bandwidth,  Wearable 
Communications  Networking  Technologies"  were  demonstrated.  Four  field-demonstrations  showed  the 
incremental  advancements  accomplished  on  the  SPARNET  system  over  the  course  of  the  base  year. 
Early-stage  implementations  of  some  Option-year  objectives  were  successfully  demonstrated  to 
showcase  the  maturing  nature  of  the  network.  Advancements  made  to  the  various  elements  of  the 
SPARNET  system  were  engineered  to  maintain  the  gracefully-adaptable  architectures  on  which  the 
system  is  based.  Enhancements  included  a  network  layer  that  supports  multiple  instructors/squads, 
integration  of  voice-driven  operation  of  the  instructor's  map  application  via  software  tools  provided  by 
Handheld  Speech  and  heart-rate  monitoring  via  a  purpose-built,  Bluetooth-enabled  daughter  board. 

The  range  of  technical  issues  that  hindered  rapid  progress  during  earlier  months  in  the  project  was 
overcome  at  an  increasingly  accelerating  pace,  as  the  contract-year  advanced.  As  reflected  in  the 
performance  shown  and  documented  in  the  final  (fourth)  demonstration,  the  schedule  was  recovered 
and  the  performance  objectives  for  Year  1  of  the  contract  were  achieved.  In  addition,  early-stage 
implementations  of  features  scheduled  for  Option  Year  1  were  also  successfully  demonstrated.  These 
features  included  operation  with  more  than  one  instructor/squad  and  recovery  of  an  off-net  trainee- 
node  via  search,  discovery  and  registration  through  a  previously-unassociated  squad. 

A  range  of  new  developmental  work  and  work  aimed  at  improving  existing  elements  of  the  overall 
design  were  successfully  undertaken.  Examples  of  the  work  include:  1)  improvements  in  CCA  circuitry; 
2)  implementation  of  a  digitally-controlled,  two-stage,  automatic-gain-control  architecture  to  improve 
dynamic  response;  3)  incremental  changes  to  the  network-layer  to  support  managed-network 
operation;  4)  design,  implementation  and  integration  of  a  bi-directional,  Bluetooth-enabled,  daughter 
board  and  accompanying  software  to  enable  connectivity  with  commercially-available  heart-monitors; 
5)  refinement  and  demonstration  911  alerts;  6)  design,  implementation  and  validation  of  bi-directional 
messaging  capability;  6)  refinement  and  demonstration  of  store-and-forward  capabilities  supporting 
network-separation  scenarios;  7)  enhancement  of  application  software  to  provide  managed-network 
capabilities  including  dynamic  time-slot  assignment/re-assignment,  bi-directional  messaging  between 
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the  TOC  and  instructor  or  TOC  and  trainees,  and  setting  status/warning  flags;  9)  implementation  and 
verification  of  code  to  permit  bi-directional  communication  between  the  instructor's  display  and  radio. 

As  the  project  progressed,  significant  advancements  in  the  ability  to  capture  and  analyze  signals  and 
messages  were  made.  Some  tools  were  engineered  to  trigger  on  user-defined  error-messages, 
produced  by  the  operating  code.  Collectively,  these  utilities  aided  the  engineering  and  debugging 
efforts,  and  the  test,  verification  and  demonstration  activities  that  were  executed  to  assure  attainment 
of  all  performance-features  and  overall  quality-levels,  established  for  each  performance-period. 

The  overarching  objective  of  the  project  was  successfully  met.  The  SPARNET  network  was  advanced  to 
TRL  5/6,  with  a  prototype  system  tested  in  a  relevant  environment,  resulting  in  successful 
demonstration  of  the  network,  including  early-stage  implementations  of  some  out-year  features.  The 
TRL  of  the  current  system-implementation  showed  clear  advancement,  over  the  course  of  the  R&D 
effort,  and  is  now  positioned  for  refinement  and  reduction  activities  aimed  at  advancing  the  system  to 
low-rate-initial-production  status. 
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